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ABSTRACT 


The  automation  of  reachability  analysis  is  an  in^>ortant  step  in  verification  of  xietwoik 
protocols.  The  monory  size  needed  for  the  full  state  analysis  of  conq)lex  protocols  is 
usually  very  large  and  not  available  on  most  of  the  syst«ns.  A  controlled  partial  search 
algorithm  “Supeitrace”  is  implemented  in  this  thesis  to  analyze  protocols  tiutt  can  not  be 
analyzed  efficiently  by  full  state  search  metiiod.  Supertrace  algorithm  provided  the 
analysis  of  large  protocols  by  generating  80%  to  95%  more  states  and  is  much  faster  as  total 
process  time  than  full  state  analysis. 

Second  problem  addressed  in  this  thesis  is  the  improvement  of  conformance  testing 
for  protocol  in^lementations.  The  ‘^conformance  testing”  is  used  to  check  that  the  external 
behavior  of  a  given  implementation  of  a  protocol  is  equivaloit  to  its  formal  specification. 
A  previously  created  procedure  for  conformaiu:e  test  sequence  generation  is  automated  in 
this  thesis  by  the  ADA  programming  language.  The  software  tool  implemented,  uses  a 
protocol  specified  formally  with  systems  of  communicating  machines  and  creates  test 
sequences  as  output  The  tool  was  applied  to  a  formal  specification  of  the  CSMA/CD  and 
FDDI  protocols  and  the  results  obtained,  was  consistent  with  the  previous  results.  The 
automation  of  the  tool  expanded  the  applicability  of  the  previous  procedure  to  larger  and 
more  complex  protocols. 


[  Accesion  For  \ 

NTIS 

CRA&I  ^ 

DTIC 

TAB  □ 

Ur.ani, 

ounced  n- 

1  Justification  j 

By 

Distribution  / 

Availability  Codes 

Dist 

H 

Avail  am. /or 

Special 

iii 


ACKNOWLEDGEMENTS 


I  would  like  to  diank  my  advisor  Prof.  G.  M.  Lundy,  who  provided  me  a  great  deal  of 
guidance  in  reachability  analysis  of  network  protocols  and  conformance  testing  of  protocol 
implen^ntadons  on  which  this  thesis  was  produced.  Ifis  continuous  support,  endiuaasm, 
and  patience  were  invaluable  assets  for  the  completion  of  this  work. 

I  also  would  like  to  thank  Prof.  Lou  Stevois,  fOT  his  interest  and  support  on  the  area 
of  my  thesis  work. 


DEDICATION 


I  dedicate  my  thesis  to  my  d^  ^e  Emei  aiul  ova  daughtei  Ipek  Ece  Nvho  wexe  my 
inqnration  for  completing  my  degree  and  kq)t  me  looking  to  the  future.  They  were  very 
supportive  throughout  my  study  program  and  gave  thdr  continuous  patience  and  love. 


TABLE  OF  CONTENTS 


l.  INTRODUCTION  _ 1 

A.  Bad^ground . . . . . . . . „.l 

B.  Scope  Of  Thesis . . 2 

C  Organization . 3 

n.  INTRODUCnON  TO  CFSM  AND  SCM  MODELS . .4 

A.  Communicating  Hnite  State  Machines . .4 

1.  Model  Definition . .4 

2.  An  Example  Of  Protocol  Specification  And  Analysis  Using  CFSM  Model . 6 

3.  Summary . 8 

B.  Systems  Of  Communicating  Machines . . 3 

1.  Model  Definitiai . 9 

2.  Algoridun:  System  State  Aiudysis . . . 10 

3.  An  Example  Of  Protocol  Specification  And  Analysis  Using  SCM  Model . 11 

4.  Summary . 13 

m.  SUPERTRACE  ALGORITHM . 14 

A.  The  Idea  Behind  The  Supeitraoe  Algorithm . 14 

1.  Supettrace  Algorithm  (A  Controlled  Partial  Search  Mefiiod) . IS 

B.  Simple  Mushroom  \ifith  Supeitraoe . 16 

1.  Program  Structure . 17 

2.  hqxit . 18 

3.  Readiability  Arudysis . 20 

4.  Ou^ . 23 

C ;  Jig  Muduoom  Supettrace . 23 

1.  Program  Structure . 23 

2.  Ii^t . 26 

a.  Rnite  State  Machines . 26 

b.  Variable  Definitions . 26 

c.  Predicate-Action  Table . 27 

3.  Global  Reachability  Analysis . 30 

4.  Ou^ . ’ . 31 

D.  Summary . 24 

rV.  A  PROGRAM  FOR  PROTOCOL  TEST  SEQUENCE  GENERATION . 35 

vi 


A.  Kntiodiiction  To  Confranwoe  Testing _ _  35 

B. TestOeneratkmProceduie -  36 

1.  Preliminaiy  Steps  .................... _ ...... - - — - - - - - - ^......37 

2.  Test  Sequence  Generating  Procedure . »~37 

3.  Refining  Stq»s _ ... — . . .38 

C  Test  Ooimtion  of  the  CSMAA!I>  Protocol . 39 

1.  Creatii^  Inputs  For  The  ‘TESTGEN**  Program . .41 

2.  Procedure  Of  The  Protocol  Test  Sequence  Generator . .44 

3.  Preliminaries . .46 

4.  Test  Sequoice  Generation ........ . .47 

5.  Refinement . .48 

V.  APPLICATIONS  OF  THE  SUPERTRACE  AND  TESTGEN  PROGRAM . .50 

A.  Applications  Of  Mushroom  Program  ^th  Supettrace . .50 

1.  CFSM  Nfodel  with  Supertrace . .50 

a.  Simple  Four  Nfochine  Protocol . .50 

b.  Analysis  Of  Information  Transfer  Phase  Of  The  Lap-B  Protocol . .54 

B.  SCM  Model  With  Supertrace . .59 

a.  Go  Back  N  Protocol ....................... . .59 

b.  Token  BusProtocol . 62 

C.  Automated  Test  Generatioi  Of  FDDI  Protocol  By  “TESTGEN”  Program . 65 

1.  Creating  Fsm  And  Predicate-action  Irqxit  Rles  For  FDDI  Protocol . 68 

VI.  CONCLUSION  AND  FURTHER  RESEARCH  POSSIBILITIES . 73 

A.  Supertrace  Algorithm . .73 

B.  TESTGEN  Program . .75 

APPENDIX  A  -  LAP-B  Protocol  Information  Transfer  niase. . 77 

APPENDIX  B  -  Go-Back-N  Protocol . 83 

LIST  OF  REFERENCES . . . .90 

INITIAL  DISTRIBUTION  LIST . .93 


vii 


L  INTRODUCTION 


A.  Background 

Sys^m  of  communicating  machines  (SCM)  [LUNDSB]  is  a  fcxmal  protocol  model 
introduced  during  die  last  decade,  which  is  used  for  qwdficatkm.  verification  and  analysis  of 
communicaritm  protocols.  The  main  goal  of  the  SCM  model  was  to  improve  die  well-known 
simpler  Ccunmunicating  Finite  State  Machines  (CFSM)  model.  In  several  pliers  die  model  wm 
used  to  specify  and  verify  several  oanmunication  protocols.  The  analysis  u^ch  is  carried  out  with 
the  model,  called  system  state  analysis,  has  been  automated.  The  SCM  model  of  a  protocol  can  then 
be  easily  verified. 

This  model  uses  a  combinadon  of  finite  state  machines  and  variables.  The  variaNes  may  be 
local  to  a  single  machine  or  shared  by  multiple  machines.  It  can  be  classified  in  the  models  known 
as  “extended  finite  state  machines.” 

The  global  stale  analysis  of  protocols  usually  generates  a  veiy  large  number  of  states.  A 
previous  wofk  [BULB93]  on  reachability  analysis,  automated  the  toialysis  of  communicatitxi 
protocols.  This  analysis  was  based  on  the  exhaustive  search  method.  The  main  restriction  widi  this 
method  is  its  inability  to  continue  processing  in  die  face  of  the  “state  space  explosion.”  As  stated  in 
[HOLZ91],  an  estimate  for  the  maximum  size  of  the  state  space  that  can  be  reached  for  a  full 
reachability  analysis  is  about  10^  states.  A  protocol  with  more  than  10^  states  cannot  be  fully 
analyzed  utilizing  the  exhaustive  search  mediod,  due  to  computer  memory  limitations.  A  controlled 
partial  seardi  mediod  "Supertrace"  was  thus  introduced  in  [HOLZ91]  to  analyze  protocols  which 
cannot  be  analyzed  by  the  exhaustive  search  method.  The  Supertrace  is  implemoited  in  this  thesis. 

A  conformance  test  is  used  to  ensure  that  the  external  behavior  of  a  protocol’s 
implementation  is  equivalent  to  its  formal  specification.  In  conducting  a  conformance  test,  we  are 
given  a  known  protocol  specification  and  an  unknown  implementatioa  The  implementation,  for 
practical  purposes,  is  considered  a  “blade  box”  widi  a  finite  set  of  inputs  and  outputs.  The  test 
provides  a  sequence  of  irqnit  signals,  and  observes  the  resulting  outputs.  The  implementation  under 
test  (lUT)  should  pass  the  test  only  if  all  observed  outputs  match  those  prescribed  by  the  formal 
spedfication.  The  series  of  input  sequoices  \riiich  are  used  to  exercise  the  protocol  implementation 
in  this  way  are  referred  as  cortformance  test  sequence  throughout  this  thesis. 

A  previous  study  [MILL90]  on  this  issue  observed  gaps  between  the  spedfication,  the 
verification,  and  the  conformance  testing  of  network  protocols.  Protocol  models  whidi  are  designed 
for  spedfication  purposes  usually  have  many  powerful  program  language  constructs,  to  simplify 
the  specification,  but  are  difficult  to  analyze.  Protocol  models  designed  primarily  for  analysis 
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pQiposes.  sttd)  as  the  C3^M  mcxtel,  are  too  simple  for  the  qwdiication  of  modem,  omiidex 
protocols.  Recent  works  cm  confonnance  testing  have  started  fimn  foe  desaiption  of  a  {notocol  as 
an  incompletely  specified  finite  state  machine  with  inpot/ouQwt  labels  on  foe  transitkxis 
[CHEN90],[DAHB90].  Protocol  specifications  are  not  nonnally  desoibed  in  this  manner 

Suppose  a  test  designer  was  required  to  test  a  protocol  specified  using  a  fonnal  language  (i.e. 
Estelle).  Rrst,  foe  specificatitm  must  be  translated  to  an  I/O  diagram.  This  is  a  labor  intensive 
complex  process,  and  during  which  errors  are  easily  introduced.  Only,  whoi  fois  translaticm  is 
complete,  can  the  designer  begin  to  generate  the  ii^ts  forcmifotmance  testing. 

A  procedure,  created  in  [LUND90A],  is  implemented  in  this  thesis,  for  the  generation  of  a 
test  sequence  for  a  protocol  specified  in  the  SCM  model.  The  purpose  was  to  reduce  the  work  and 
the  possibility  of  error,  for  the  designer.  The  automation  of  the  conformance  test  sequence 
generation  is  also  an  attempt  to  close  the  gap  between  specificatioit/verification  and  testing  of 
protocols.  In  this  thesis,  the  test  generation  starts  from  a  protocol  model,  designed  for  tiie 
specification  and  verification  of  protocols.  The  procedure  [LUND90A]  and  its  automation  as  a 
software  tool  does  not  guarantee  that  all  the  errors  or  combination  of  errors  in  a  protocol  are  found. 
But  they  do  represent  an  attempt  to  exercise  aU  parts  of  tiie  protocol,  providing  some  assurance  that 
the  implementation  meets  its  purpose. 

B.  Scope  Of  Thesis 

The  scope  of  this  thesis  is  two  fold:  The  first  is  to  presort  implementation  of  tire  Supertrace 
algorithm,  sqrllied  to  the  CFSM  and  SCM  protocol  models.  This  leads  to  the  reachability  analysis 
of  larger  potocols  formally  specified  by  CFSM  and  SCM  models  that  caiuiot  be  totally  analyzed 
by  using  exhaustive  search  metiiods.  An  earlier  study  on  this  issue  is  capable  of  generating 
teachability  analysis  of  protocols  that  are  small  enough  to  be  analyzed  by  full  state  ^race  search 
method.  This  thesis  expands  this  work  to  cover  the  analysis  of  bigger  protocols  by  a  cmtrolled 
partial  search  method  known  as  "Supertrace"  algorithm.  The  output  of  the  program  was  compared 
to  several  previous  works  and  was  consistent  with  their  results. 

The  second  part  of  this  thesis  is  on  testing  protocol  implementations.  A  software  tool  that 
automates  the  generation  of  a  testing  sequence  is  introduced  for  testing  and  verification  of  network 
protocols.  The  procedure  implemented  in  this  program  was  created  in  [LUND90A]. 

When  combined  with  the  earlier  work  a  protocol  can  be  specified  as  a  system  of 
communicating  madhines,  analyzed  by  the  mushroom  program  and  a  set  of  “conformance  tests”  can 
be  generated  from  to  insure  that  an  impiementati(Hi  of  the  protocol  is,  to  some  degree  at  least,  in 
conformance  wifo  its  specification 
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C.  Organization 

This  thesis  has  six  chapters.  C3u^r  n  reviews  die  Communicating  Hnite  State  Machines 
(CFSM)  and  System  of  Communication  (SCM)  models.  Chapter  m  describes  the  Super  Trace 
algoridun  and  introduces  two  programs  based  on  the  algorithm.  The  Sinqile  Mushroom  With 
Supertraoe  and  Big  Mushroom  With  Supertrace,  expand  the  automaticHi  of  die  global 
reachabiUty  analysis  of  larger  protocols  formally  qiecified  by  CFSM  and  SCM  models 
reflectively. 

In  Chapter  IV,  a  procedure  for  generating  test  sequoices  for  a  fonnally  specified  protocol  is 
introduced  and  a  software  tool  that  automates  this  process  is  described. 

In  Chfiter  V,  examples  of  the  use  of  software  tools  are  given. 

Chapter  VI  concludes  the  thesis  with  a  research  review  and  suggestions  for  future  work. 
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n.  INTRODUCTION  TO  CFSM  AND  SCM  MODELS 


A.  Communicating  Finite  State  Machines 

Communicating  finite  state  machine  (CFSM)  model  is  a  sim^de  model  which  requires  diat 
each  machine  in  the  netwoik  is  modeled  as  a  finite  automaton  or  finite  state  machine  (FSM).  The 
Cnmmiinigatifm  diaimels  between  pairs  of  machines  are  modeled  as  one-way,  infinite  loigfii  FIFO 
queues.  There  is  a  great  deal  of  literature  on  this  model  CPENG91][RUDI86][VUON83].  The  model 
is  defined  for  an  aibitrary  number  of  machines.  A  two  machine  model  (shown  in  Hgure  1)  will  be 
presented  in  this  dtapter  for  simplicity. 


Rgurc  1 :  CFSM,  Two  madiine  model  r^iesentation 


1.  Model  Definition 

TtJs  section  defines  the  CFSM  model  (GOUD831  and  provides  a  simple  protocol 
specification  and  analysis  to  clarify  die  definiticm. 

A  communicating  machine  Af  is  a  finite,  directed  labeled  gnqdi  with  two  types  of  edges, 
sending  and  receiving.  A  sending  (receiving)  edge  is  labeled  ‘-g'  (‘+g’)  for  some  message  g,  taken 
firom  a  finite  set  G  of  messages.  One  of  the  nodes  in  Af  is  identified  as  die  initial  node  by  some 
directed  path.  A  node  in  M  whose  outgoing  edges  are  all  sending  (receiving)  edges  is  a  sending 
(receiving)  node;  odierwise  the  node  is  a  mixed  node.  The  nodes  of  M  are  often  referred  to  as  states; 
these  two  terms  will  be  used  interchangeably  throughout  this  thesis. 

Let  M  and  N  be  two  communicaring  machines  having  the  same  set  G  of  messages  the  pair 
(Af,iV)  is  a  network.  A  global  state  of  this  netwoik  is  a  four  tuple  [m,  c^,  n,  cj,  where  m  and  n  are 
nodes  (states)  from  Af  and  iV,  and  and  c„  are  strings  from  die  set  G  of  messages.  Intuitively,  die 
global  state  [m,  c„,  n,  c„]  means  that  the  machines  Af  and  N  have  readied  states  m  and  n,  and  the 
communication  diannels  contain  the  strings  c„  and  of  messs^es,  where  c„  denotes  the  messages 
salt  ftom  M  to  N  in  channel  and  c„  denotes  the  messages  sent  from  to  Af  in  diamiel  Cy.  hi 
the  case  of  say  k  number  of  madiines  where  k  >  2  the  global  state  can  be  represented  as 
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«••• ••••  jnipQid^ia*—^  where  mi’s  are  die  nodes  of  machines 

A#,- and  ^lyOHitains  the  messages  salt  from  Al,- to  My.  Subscripts  i  and  j  ranges  from  i.Jk  and  i  ^  j. 

The  initial  global  state  of  (M/f)  is  [mo^,  no^,  vriiere  mo  and  are  die  inidal  states  of 
M  and  A^,  and  £  is  die  emi^  string. 

The  network  progresses  as  transitions  are  taken  in  either  Af  orN.  Each  transition  consists 
of  a  state  change  in  one  of  the  machines,  and  eidier  the  addition  of  a  message  to  the  end  of  one 
channel  (sending  transition)  or  the  deletion  of  a  message  from  die  front  of  one  channel  (receiving 
transition). 

A  sending  transition  in  Af  (A^j  adds  a  message  to  the  end  of  channel  C14  (C^j;  a  receivii^ 
transition  in  Af  (A^)  removes  a  message  from  the  front  of  cl;annel  Cff  (€33). 

Suppose  +g  is  a  receiving  transition  from  state  i  toy  in  machine  Af  (N).  The  transition  can 
be  executed  if  and  only  if  Af  (N)  is  in  state  i  and  die  message  g  is  at  the  front  of  the  channel  Cff  (€33). 
The  execution  takes  zero  time.  After  its  execution,  machine  Af  (N)  is  in  state  j,  and  the  message  g 
has  been  removed  from  the  channel  Cf/  (C3/). 

Similarly,  suppose  -  g  is  a  sending  transiticm  from  state  1  to  y  in  machine  Af  (AO.  The 
transition  can  be  executed  if  and  only  if  Af  (N)  is  in  state  i.  Afterwards,  g  appears  on  the  aid  of  the 
outgoing  channel,  and  die  machine  has  transitioned  to  state  j. 

Suppose  [m,  q,  n,  cy]  is  a  global  state  of  (Af,A0.  State  $2  follows  sj  if  diere  is  a 
transition  (in  Af  or  AO  which  can  be  executed  in  s/  if  there  is  a  sequence  of  states  s,-,  s,+y s,  +p  such 
that  Si  follows  sj,  Si+j  follows  s,-,  and  so  on,  and  S2  follows  A  state  s  is  reachable  if  it  is 
reachable  from  the  initial  state. 

The  communication  of  a  network  (JMff)  is  a  directed  gnqdi  in  which  the  nodes 
correspond  to  the  reachable  global  states  of  (Af,^,  and  the  edges  refnesent  die  follows  functioiL 
That  is,  there  is  an  edge  from  state  s,-  to  state  sj  if  ad  only  if  sj  follows  s,-.  The  edges  are  labeled  with 
the  transitions  which  they  represent  This  reachability  grai^  can  be  goierated  by  starting  with  the 
initial  state,  and  adding  the  states  which  follow  it  connecting  diem  to  it  with  edges;  and  repeating 
for  each  new  state  generated. 

The  next  two  definitions  are  of  errors  that  may  occur  in  a  communication  protocol  which 
are  detectable  by  analysis. 

A  global  state  [m,  Cm,n,  c  J  is  a  deadlock  state  if  both  m  and  n  are  receiving  nodes  and 

where  E  doiotes  the  empty  string. 

A  global  state  [m,  c^/i,  c„]  is  an  unspecified  reception  state  if  one  of  the  following  two 
conditions  is  true: 
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(1)  m  is  a  receiving  state,  the  message  at  the  head  of  channel  is  g,  and  none  of  m’s 
outgoing  tnuisititnis  is  labded 

(2)  n  is  a  receiving  state,  the  message  at  die  head  of  the  diaraiel  is  g,  and  ncrne  of  n ’s 

outgoing  tnmsitions  is  labeled  ‘4-g.* 

These  enor  conditions  can  be  identified  by  goierating  die  reachability  for  anetwoik,  and 
inspecting  all  states  as  they  are  generated.  In  the  i^t  section,  an  example  inotocol  is  specified  and 
analyzed  using  CFSM  model. 

2.  An  Example  Of  Protocol  Specification  And  Analysis  Using  CFSM  Model 

A  simplified  version  of  die  Stop-and-Wait  data  link  protocol  will  be  analyzed  as  an 
example  of  analysis  with  CFSM  model.  The  interface  between  user  and  data  link  layer  are  assumed 
to  be  error  free  and  higher  layer  passes  information/frame  widiout  error  to  die  Data  link  layer.  At 
data  link  layer  this  protocol  consist  of  two  machines  a  sender  and  a  receiver.  In  Hgure  2,  machine 
1  serves  as  the  sender  and  machine  2  serves  as  the  receiver. 


Machine  1  Machine  2 


Figure  2 :  CFSM  Specification  for  Stop>and-Wait 

The  sender  places  a  frame  on  die  channel  for  the  receiver.  The  receiver  senses  a  frame  on 
the  incoming  channel  and  accepts  and  removes  the  message  from  die  channel.  The  receiver  dien 
sends  an  acknowledgment  packet  to  the  sender.  The  sender  receives  the  acknowledgment  packet 
and  is  able  to  send  another  frame  of  information  to  the  receiver. 

The  -D  and  +D  represents  the  soiding  and  receiving  of  data  respectively.  The  -A,  and  +  A 
represent  the  sending  and  receiving  acknowledgment  respectively.  Since  the  initial  state  of  each 
machine  is  0;  the  initial  global  state  is  [0,E,0,E]. 

The  reachability  analysis  can  be  done  by  a  simple  procedure.  Starting  with  the  initial 
global  stale  only  one  transition  is  possible,  die  -D  of  machine  1  fiom  state  0.  This  leads  to  global 
state  [  1,D,0£].  We  can  continue  die  analysis  in  the  same  manner  detecting  the  possible  transitions 
from  this  global  state  until  possible  global  states  are  found.  The  complete  reachability  analysis 
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consisting  of  four  ststes  is  given  in  Hguit  3.  There  are  no  deadlocks  or  unqwdfied  lecqidans  in 
this  protocol. 

- ^O.E.O.E] 

|.D 

[l.DjO.E] 

[I.e'i.E] 

I'* 

H.E.O.A] 

Hgure  3 :  Reachability  Analysis  of  Stop-and-Wait  protocol 

Another  CFSM  specification  of  an  imaginary  networic  protocol  consisting  of  ttiiee 
communicating  machines  is  shown  in  Hgure  4. 

Machine  1  Machine  2 


Hgure  4 :  CFSM  Specificaticm  of  Example  protocol 

The  directed  edges  are  labeled  sudi  that  the  character-number  combinations  following 
the  *-/+’  shows  the  messages  and  the  numbers  at  foe  end  rqnesent  the  destination  machine.  A 
clockwise  ring  is  formed  with  each  machine  sending  one  message  to  foe  next  machine  and  receiving 
a  message  from  the  previous  machine.  The  initial  state  of  each  machine  is  1;  thus  the  initial  global 
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state  is  The  leadiability  analysis  of  this  {MXMoccri  shown  in  Hguie  S.  In  tiiis 

analysis  there  is  one  deadlodc  condition  and  one  unq)ecified  reoq;iti(ML  In  global  state 
[3£JE,3££,1JB»E],  all  die  channels  are  empty  and  all  die  nodes  are  recdving  nodes  satisfying  the 
deadlock  condition.  In  global  state  [2f  f  ,1JE3.3,D4JB],  madiine  1  and  machine  2  are  in  receiving 
states  but  none  of  the  outgoing  transitions  are  labeled  satisfying  an  unspecified  recqithm 
coiKlition. 


3.  Summary 

The  CFSM  model  is  simple  and  easy  to  understand.  However,  as  die  protocols  become 
more  complex,  this  model  becomes  difficult  to  use  due  to  a  comtanatorial  explosion  of  states.  The 
analysis  might  not  terminate  if  die  queue  length  is  unbounded.  The  number  of  states  in  the 
reachability  graph  will  be  unmanageably  large  for  such  complex  protocols  evoi  if  the  queue  length 
is  bounded.  A  computer  analysis  might  eventually  terminate,  but  still  the  CPU  time  would  be  days 
even  months,  obviously  impractical. 

Another  disadvantage  is  that  as  the  protocols  become  more  complex,  the  specification  of 
the  protocol  can  be  so  large,  consisting  of  many  states  and  transitions,  that  makes  it  very  hard  to 
understand  if  it  is  the  intended  specification.  Several  examples  are  givoi  in  Charter  V  that  shows 
the  largoiess  of  analysis  output  for  smne  protocols. 
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B.  Systems  Of  Communicating  Machines 

In  this  section  die  SCM  model  is  described.  Hist  the  model  defiidtian  is  given,  dun  the 
algoridim  fior  generating  the  system  state  analysis  is  described.  Rnally,  to  illnstrale  die  important 
aspects  of  the  model  it  is  used  to  ^)ecily  analyze  a  samfrie  protood. 

1.  Modd  Definition 

A  system  of  communicating  machines  is  an  ordered  pair  (M,V),  where 

M=  {mi4n2....4n„} 

is  a  finite  set  of  machines,  and 

V=s  {Vi,V2,...,Vk) 

isafinites^of  shared  variables  widi  two  designated  subsets /I,*  and  fV/q)ecified  for  each 
machine  m,-.  The  subset  R-,  of  V  is  called  the  set  of  read  access  varitddes  for  madiine  m,-,  and  die 
subset  Wi  the  set  of  write  access  variables  form;. 

Each  machine  m,-  6  M  is  defined  by  a  ti^le  whme 

(1)  Si  is  a  finite  set  of  states; 

(2)  s  €  Sf  is  a  designated  state  called  die  initial  state  of  m/; 

(3)  Li  is  a  finite  set  of  local  variables', 

(4)  Ni  is  a  finite  set  of  names,  each  of  uriiich  is  associated  with  a  unique  pair  (p/t),  where 
p  is  a  {Hcdicate  on  the  variables  L,-  vj  Rj,  and  a  is  an  acdon  on  die  variables  of  u  Rj  u  Wi. 
Specifically,  an  action  is  a  partial  funcdon 

a:  LiXRi^LiXWi 

from  the  values  of  the  local  variables  and  read  access  vaiiaUes  to  the  values  of  die  local 
variables  and  write  access  variables. 

(5)  Xf.  Sj  X  Ni  Si  is  a  transition  function,  which  is  a  partial  function  from  the  states 
and  names  of  m/to  the  states  of  m,-. 

Machines  model  die  entities,  which  in  a  protocol  system  are  processes  and  diannels.  The 
shared  variables  are  the  means  of  communication  between  the  machines.  Intuitively,  Ri  and  Wi  are 
the  subsets  of  V  to  iiriiich  mi  has  read  and  write  access,  respectively.  A  machine  is  allowed  to  make 
a  transition  from  one  state  to  another  whoi  die  predicate  associated  widi  die  name  for  that  transition 
is  true.  Upon  taking  the  transition,  the  action  associated  with  diat  name  is  executed.  The  action 
changes  the  values  of  local  and/or  shared  varialdes,  thus  allowing  other  predicates  become  tnie. 

The  sets  of  local  and  shared  variables  ^ledfy  a  name  and  range  for  each.  In  most  cases, 
the  range  will  be  a  finite  or  countable  set  of  values.  For  proper  operation,  die  initial  values  of  some 
or  all  of  die  variables  should  be  specified. 


9 


A  system  state  tuple  is  a  tafit  of  all  macfaine  states.  That  is,  if  (M^V)  is  a  system  of  n 
coinmunicatiiig  madhines,  and  Sj,  for  I^i^n  .  is  the  state  of  die  machine  ntj,  dien  the  n-tiq;ile 
(Si.52,...4|i)  is  die  system  state  hqde  of  (M,V).  A  system  suae  is  a  system  state  tiqde.  plus  die 
outgoing  transitions  which  are  enabled.  Thus  two  system  states  are  equal  if  evety  machine  is  indie 
same  state,  and  the  same  outgoing  transitions  are  enatded. 

The  global  state  of  a  system  consists  of  the  system  state  tiqile,  plus  die  values  of  all 
variables,  both  local  and  shared.  Itmay  be  written  as  a  larger  tuple,  containing  die  system  state  tiqde 
with  the  values  of  the  variables.  The  initial  global  state  is  the  initial  system  state  tiqde,  widi  the 
additional  lequiremoit  that  all  variables  have  their  initial  values.  The  initial  system  state  is  die 
system  state  such  that  every  madiine  is  in  its  state,  and  die  outgoing  transitkms  are  the  same  as  in 
the  initial  global  state. 

A  global  state  corresponds  to  a  system  state  if  every  madiine  is  in  the  same  state,  and  die 
same  outgoing  transitions  are  enabled.  Qeariy,  more  than  one  global  state  may  correspcmd  to  the 
same  state. 

Let  t(si/i)  =  S2  be  a  transition  which  is  defined  on  machine  m,-.  TTansitim  X  is  enabled 
if  die  enabling  predicate  p,  associated  with  name  n,  is  true.  Transition  x  may  be  enabled  whenever 
mi  is  in  state  si  and  the  predicate  p  is  true  (oiabled).  The  execution  of  X  is  an  atinnic  action,  in  iiriiidi 
both  the  state  diange  and  the  action  a  is  associated  with  n  occur  simultaneously. 

It  is  assumed  that  if  a  transition  is  enabled  indefiiiitely,  dien  it  will  eventiially  occur.  This 
is  an  assumption  of  fairness,  and  is  needed  for  the  proofs  of  certain  properties. 

2.  Algorithm:  System  State  Analysis 

The  process  of  generating  the  set  of  all  system  states  readiable  from  the  initial  state  is 
called  system  state  analysis.  This  analysis  construct  a  gnqdi,  iiriiose  nodes  are  die  reachable  system 
states,  and  whose  arcs  indicate  the  transitions  leading  hom  each  system  state  to  another.  This  gtrqih 
may  be  generated  by  amechanical  procedure  vriiich  consist  of  the  following  diree  steps  [LUND91]; 

1.  Set  each  madiine  to  its  initial  state,  and  all  variables  to  dieir  original  values.The  initial 
set  of  reachable  system  states  consists  of  only  the  initial  system  state;  die  initial  graph  is  a  single 
node  representing  diis  case. 

2.  From  the  current  system  state  vector  and  variable  values,  determine  idiidi  transitions 
are  enabled.  For  eadi  of  these  transitiois  determine  the  system  state  \riiidi  results  from  its 
executioa  If  this  state  (with  the  same  enabled  transitions)  has  already  been  generated,  then  draw  an 
arc  horn  die  current  state  to  it,  labeling  the  arc  with  the  transition  name.  Otherwise,  add  the  new 
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system  stale  to  the  graph,  draw  an  arc  from  the  cuirent  ttale  to  tt,  nd  Ubd  tbe  MC  widi  the  name  of 
the  transition. 

3.  For  eadi  new  state  generated  in  step  2.  rqieat  step  2.  Oonlinie  mnil  step  2  hut  initial, 
been  repeated  for  each  system  state  thus  goieiated,  and  no  more  new  stales  me  feaenied 

3.  An  Example  Protocol  Specification  and  Analysis  Using  SCM  Model 

The  stop-and-wait  protocol  is  also  used  to  demonstrate  the  analysis  using  SCM  model. 
The  specification  of  the  stop-and-wait  protocol  as  represented  by  SCM  model  is  shown  in .  The 
specification  consists  of  two  finite  state  machines,  the  local  and  shared  variables,  and  the  {uedicate 
action  table.  Table  1 .  The  local  variables  are  in_buff  and  out_biiff  shown  under  thdr  corresponding 
FSMs.  The  shared  variables  are:  CHAN  and  RET  and  shown  between  toe  two  machines.  The  initial 
state  of  each  machine  is  0,  with  the  shared  and  local  variables  are  empty  exeqx  the  local  variaUe 
outjbuff  which  has  “D.”  The  ‘D’  in  outjbuff  rqnesents  and  characters  ‘E’  and  ‘A’  in  predicate 
action  table  represent  empty  string  and  acknowledgmott  respectively. 

Machine  1  Machine  2 


Hgure  6 :  SCM  Specification  of  Stop-and-Wait  Protocol  with  Variables 


TABLE  1:  PREDICATE  ACTION  TABLE  FOR  STOP-AND-WAIT  PROTOCOL 


'liansition 

Enabling  Predicate 

Action 

Snd_data 

CHAN  =  E  A  out_buff  ^  E 

CHANrs  out.buff 
oiit_bi]£r:s  E 

Rcv_Ack 

RET»A 

RET:=E;CHAN:»E 

Rcv.data 

CHAN^feE 

in_biiff:sCHAN 

Snd_Ack 

TRUE 

RET:s  A ;  in_buff:a  E 
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I^rtids  examide  the  assuoqjtkm  is  made  that  data  is  always  nude  cvalUble  to  die  CHAN 
finm  ouUMiff.  The  global  reachability  anaiysis,  diown  in  Hgure  7,  has  4  states.  The  finiiiat  ft»' the 
global  state  tuple  is: 

[Machineljstate,  ouUwff,  Machine2...State,  ipjbuff.  CHAN,  RET] 

- ^0X>,0.EAE] 

J-D 

[1J),0.E4),E] 

h 

[1A1.DAE] 

[1J),0,DAA] 

I 

Hguie  7 :  Global  Reachability  Analysis  of  Stop-and-Wait  Protocol 

The  system  state  analysis  for  die  stq>>and-waiti»otocol  also  has  4  states  (see  Hguie  8). 
For  more  complex  protocols,  ttione  may  be  a  big  diffmence  between  global  and  system  states.  For 
example  a  sliding  window  protocol  with  a  window  size  of  8  the  system  state  analysis  was  shown  to 
generate  165  states,  while  the  foil  global  analysis  generated  11880  states  [LUND91I. 

The  format  for  a  system  state  tuple  analysis  is: 

[Machineljstate ,  Machine2_state] 


Hgute  8  :  System  Reachability  Analysis  of  Stop-and-Wait  Protocol 
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4.  Summary 

The  SCM  model  has  desiraUe  piopeities  which  overcome  some  of  the  disadvantages  of 
the  CFSM  model.  One  of  die  advantages  of  the  SCM  model  is  that  it  significandy  reduces  die  state 
explosion  ihrou^  die  use  of  system  state  aiudysis.  In  some  cases,  however  the  systmn  state  analysis 
is  not  suffidoit  for  protocol  analysis.  Some  other  method  -  sudi  as  global  analysis  must  be 
performed.  A  problem  is  that  loops  in  die  state  machines  may  cause  an  insufBdent  systm  state 
analysis. 

Another  advantage  of  SCM  model  is  that  it  allows  communication  between  machines  in 
nonsequential  manner,  unlike  a  FIFO  queue  representation  in  die  CFSM  model.  The  SCM  model 
spedfication  is  easier  to  understand  than  the  CFSM  model  for  more  complex  protocols 
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m.  SUPERTRACE  ALGORITHM 


A.  The  Idea  Behind  The  Supertrace  Algorithm 


The  standanl  hill,  or  exhaustive,  seaidi  algoridim  eiqilores  all  leachaUe  cooqx)^  syston 
states  for  a  s^  of  interacting  finite  state  machines.  Every  leacfaable  state  and  eveiy  sequence  of 
reachaUe  states  can  be  checked  for  a  set  of  correctness  oiteiia  sudi  as  deadlock  omditirm  and 
unspecified  lecqjtirm.  However,  foe  size  of  foe  search  space  and  the  limits  of  physical  memoiy 
severely  restrict  foe  use  of  this  method.  If  foe  size  of  foe  state  space  is  jg  and  foe  maximum  numbCT 
of  states  foat  can  be  stored  in  memoiy  during  the  search  is  M  bofo  foe  coverage  and  foe  searcfo 
quality  can  only  readi  100%  vfoeni?^M.  When /g>M  the  coverage  reduce  to  Af/J?,botfoe 
search  quality  is  likely  to  be  worse. 

To  give  an  idea  of  foe  magnitude  of  such  a  search  consider  foe  following  examide.  Suppose 
that  we  have  a  protocol  for  two  machines,  each  wifo  100  states,  one  message  queue,  and  five  local 
variables.  The  two  message  queues  are  restricted  to  five  slots  each,  and  the  range  of  values  for  local 
variables  are  assumed  to  be  limited  to  tmi  values.  The  number  of  distinct  messages  exchanged  is  10. 
In  this  sample  system,  there  are  10  possible  states  of  foe  protocol  variables.  Eadi  process  can 
be  in  one  of  10^  differoit  states,  so  two  processes  can  maximally  be  in  10^  difosient  composite 
system  states.  Finally  each  queue  can  hold  up  to  five  messages,  where  each  message  can  be  one  out 
of  ten  permutations.  The  total  number  of  system  states  in  foe  worst  case  is 


10*®- 10^- 


or  in  foe  order  of  10  different  states.  If  each  state  could  be  encoded  in  1  byte  of  mmnory 
and  analyzed  in  10~®  sec,  it  would  still  require  at  least  10*^times  more  memory  as  currently 
available  on  most  systems,  and  would  take  roughly  10**  years  to  perform  an  exhaustive  analysis. 

Fortunately,  the  number  of  effectively  reachable  states  is  usually  much  smaller  foan  foe  total 
number  of  states  calculated  above.  Evoi  relatively  small  protocol  systems,  however,  can  easily 
generate  up  to  10  reachable  states.  Therefore  the  full  search  method  is  feasiUe  only  if  we  can 
reduce  foe  complexity  of  our  models  to  the  maximum  that  a  given  madiine  can  analyze. 

If  the  state  space  is  larger  than  the  available  memory  can  accommodate,  foe  exhaustive  search 
strategy  discussed  above  reduces  to  a  partial  search,  without  guaranteeing  that  foe  most  important 
parts  of  the  protocol  are  inspected.  This  observation  has  led  to  foe  development  of  a  new  class  of 
algorithms  that  exploits  the  benefits  of  partial  search. 
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One  of  the  most  effective  paitial  search  methods  is  die  ‘'Siqieitiace  Algorithm"  [HOLZ91]. 
vtdiich  is  implemented  in  this  thesis. 

1.  Supertrace  Algorithm  (A  Controlled  Partial  Search  Method) 

hi  this  section  the  idea  behind  die  supertrace  will  be  discussed  as  it  is  introduced  in 
[HOLZ91]. 

Let  A  represent  our  state  space  s^  and  M  the  bytes  of  memory  available.The  standard 
way  to  maintain  the  state  space  set  A  is  using  a  technique  called  hashing.  Redundant  states  are 
restricted  from  set  A  by  means  of  a  hashing  funcdon. 

Each  is  placed  into  a  hashing  table  based  on  dieir  hashing  value  h(s)=i  where  k  is 
the  ha.shing  function,  s  is  the  global  state,  and  i  is  the  index  for  the  hash  lotdcup  taUe  (see  Figure  9). 


Figure  9 :  Hash  Lookup  Table 

If  we  have  H  slots  in  the  hash  lookup  table.  Ha^  function  h( s)  must  be  defined  sudi  tiiat 
it  retums  arbitrary  value  i  in  the  range  ),  But  the  possibility  exists  that  two  different  states 
produce  the  same  hash  value.  In  the  case  of  a  large  protocol  the  hash  table  will  have  to  accommodate 
a  large  number  of  states.  When  A  >  H  the  hash  function  will  always  produce  some  duplicates 
indices  values  of  i  for  an  averse  of  A/ff  diHerent  states.  To  accominodate  these  duplicate  iiuiex 
values  we  use  an  open  hash  and  all  states  that  hash  to  the  same  value  ate  stored  in  a  linked  list  that 
is  accessible  via  the  lotricup  table  under  the  calculated  index.  When  the  table  is  foil,  each  new  state 
must  be  compared  to  average  AIH  other  states  before  it  can  be  inserted  into  u.2  linked  list  or 
discarded  as  redundant  As  A  continues  to  grow  beyond  ttie  first  H  states,  the  number  of 
comparisons  required  increases  steadily,  and  the  seardi  efficiency  degrades.  There  is  atime  penalty 
for  aruilyzing  systons  of  more  than  H  states.  This  type  of  hashing  was  used  for  analysis  of  protocols 
in  previous  woric  (BULB93]. 
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We  want  to  nuke  H  as  Ug  as  pojssilde  or  at  least  10^  timesUggertbanwee^^KctAto 
be.  If  we  can  have //»  A  then  ttieie  will  be  very  few,  if  any,  conflicts.  In  this  case  we  do  not  need 
to  store  complete  state  descriptimis  in  the  hash  table:  in  all  bm  a  few  cases  the  haali  value  h(s) 
uniquely  identifles  a  state.  A  single  bit  of  storage  will  suffice  to  verify  if  a  state  has  already  been 
generated. 

If  we  have  M  bytes  of  memoiy  available,  assuming  8  bits  per  byte  we  have  iM  bits  for 
state  space.  The  state  is  not  stored.  Since  no  state  is  stored,  memoiy  effidency  is  greatly  increased 
and  tture  are  no  states  to  compare  a  new  state  against  The  bit  position  in  die  hash  table  uniquely 
identifies  the  state.  The  method  can  be  expected  to  woik  well  if  the  state  space  is  sparse  and  indeed 
H  is  veiy  large.  For  H»A  hash  conflicts  are  rare.  When  A>H  then  conflicts  will  occur.  The 
accuracy  of  our  analysis  will  dqpoid  upcxi  the  pmcentage  of  hash  conflicts.  Because  of  hash 
conflicts  some  deadlocks  or  unspecified  recqitions  may  go  undetected.The  method  therefore 
approximates  an  exhaustive  search  for  smaller  protocols  and  slowly  changes  into  a  controlled 
partial  search  mediod  for  larger  protocols.The  Stqieitrace  Algoridim  as  compared  to  the  exhausdve 
search  can  not  guarantee  100%  coverage  due  to  possibility  of  unresolved  hash  conflicts.  The 
implementation  of  the  “Supeitrace  Algorithm”  will  be  explained  in  the  following  sections. 

B.  Simple  Mushroom  With  Supertrace 

The  first  program  to  be  examined  is  called  Mushroom  with  Supeitrace.  It  was  written  in  the 
Ada  programming  language.  Mushroom  was  written  to  automate  the  reachability  analysis  of 
protocols  specified  by  die  CFSM  and  SCM  models  [BIJLB93].  The  Mushroom  with  Supeitrace  was 
developed  to  extend  the  iq^licability  of  Mushroom  program  to  laiger  and  more  complex  programs. 
There  are  actually  two  separate  versions.  The  first  called,  simple  mushroom  widi  supertrace, 
analyzes  the  CFSM  models.  The  second  version  analyzes  the  SCM  models,  eidier  as  system  state 
analysis  (smart  mushroom),  or  a  foil  global  analysis  (big  mushroom  widi  supeitrace)  of  a  protocol 
specified  formally  by  the  SCM  model.  The  Supeitrace  algoridim  is  not  implonented  for  smart 
mushroom  program  since  the  state  space  generally  does  not  grow  beyond  the  limits  of  memory.  The 
General  stracture  of  mushroom  inogiam  is  shown  in  Hgure  10. 

The  explanation.  Simple  Mushroom  with  Supeitrace,  is  divided  into  four  sections:  program 
structure,  inputs,  reachability  analysis,  and  ouqnits.  The  portions  of  this  program  that  are  common 
to  the  original  Mushroom  program  along  widi  the  details  of  the  mushroom  program  are  iu)t 
discussed. 
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Hguic  10 :  General  Stnicture  of  Mushroom  Program 
1.  Program  Structure 

The  Simple  Mushroom  program  consists  of  Ada  subprograms  ^)rocedurcs  and 
functions),  which  are  separate  compilation  units  and  subunits  of  compilation  units.  Related 
subprograms  are  also  gathered  in  the  jame  files.  The  compilation  units  of  the  program  are  shown  in 
Tabie  2.  Ptoceduie  main  is  the  parent  unit  All  of  die  subprograms  are  die  subunits  of  procedure 
mcUn  [ANSIMIL93]. 


TABLE  2:  SIMPLE  MUSHROOM  COMPILATION  UNITS 


Compilation  Unit 

Deaciqition 

File  Name 

maiii(procedure) 

This  is  die  parent  unit  Craitains  the  main 
data  structures,  global  variable 
and  the  driver: 

tmairui 

load_niachine_aiiay 

(procedure) 

Builds  the  adjacency  lists  frrnn  FSMs. 

tinpuLa 

read_in_file(procedure) 

Parses  die  input  FSM  tem  file 

tiiq>ut.a 

buildjGstatB_giaph 

(procedure) 

Generates  the  teachability  gnqih. 

treachability.a 

IsEqual  (function) 

Compares  two  global  states  for  equality 

tieachabilty.a 

hashffunctkm) 

Generates  an  index  number  according  to  the 
hashing  function 

treachabilty.a 

cIear_poinms(procedure) 

Deallocates  tire  dynamic  memory  space  for 
another  analysis 

tteachability.a 

Print  Queue(procedure) 

Prints  the  FIFO  queues 

touqnita 
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TABLE  2:  SIMPLE  MUSHROOM  COMPILATION  UNITS 


Compilation  Unit 

DescrqMkm 

File  Name 

output_Gsiate_transition  (proce¬ 
dure) 

OuqHits  the  transition  name 

touqnita 

output_Gsiale_node 

(iHwedure) 

Ouqnits  the  machine  states,  unspecified 
tecqMkms,  and  die  states  with  deadlocks. 

touqnita 

output_machine_anays 

([vocedure) 

Ouqnits  the  FSM  descriiMion  in  a  tabular 
format 

touqniLa 

ouq)ut_unexecuted_tiansitions 

(prKedure) 

Ouqiuts  the  unexecuted  transitions 

touq>ut.a 

create_ouqMt_file  (procedure) 

Creates  an  ouqnit  file  for  stming  the 
analysis  results 

touiputa 

output_analysis(procedure) 

Driver  for  the  ouqiut  subprograms 

touqnita 

system_call(procedute) 

Interface  inocedure  for  Unix  system  calls 
viaC. 

tsystema 

message_qu«ies  (package) 

Implements  the  queue  opoations  for  the 
FIFO  communication  channels. 

tqueuesa 

pointer.queues 

(genetic_package) 

Implemoits  the  queue  tqiaations  for  the 
pointer  queue  that  stmes  the  global  tuples 
temporarily 

tqueues_2.a 

2.  Input 


The  CFSM  specification  of  a  protocol  consists  of  only  FSMs  of  the  communicating 
machines.  FSMs  are  represented  with  a  text  file.  The  user  enters  the  directed  graphs  as  a  text  file 
using  some  reserved  words,  numbers,  and  characters.  For  the  list  of  reserved  words  the  reader 
should  refer  to  [BULB93].  The  maximum  number  of  machines  allowed  is  eight,  and  die  number  of 
states  for  each  machine  can  be  from  0  to  SO.  Transition  names  must  be  at  most  three  characters  long 
and  may  be  any  combination  of  letters  or  digits.  These  constraints  can  be  relaxed  with  modifications 
to  the  program,  if  necessary. 

The  input  file  for  the  stop-and-wait  protocol  in  Chapter  n  for  the  CFSM  model  is  shown 
in  Figure  1 1.  The  reserved  word  “state"  represents  the  states  of  the  machine  that  they  come  after. 
For  example  “trans  -D 1 2”  (first  line  at  state  1  in  machine  1)  represoits  a  transition  from  state  0  to 
statel  by  sending  D  to  machine  2.  The  first  character  or  *+’  following  reserved  word  “state” 
represents  sending  or  receiving  data  respectively.  “Initial.state  0  0”  means  that  the  initial  states  of 
machine  1  and  machine  2  are  state  0. 

First,  this  file  is  parsed  by  read_in_file  procedure  and  tokens  are  goierated.  Then, 
Load.machine.anay  procedure  constructs  an  adjacency  list  which  represents  die  FSMs. 
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•tart 

nuibar_of_iMcbiMa  2 

Mchina  1 

■tata  0 

traiM  -D  1  3 

■tata  1 

trana  *A  0  2 

aachlna  2 

■tata  0 

trana  40  t  1 

■tata  1 

trana  -A  0  1 

lnitlal_atata  0  0 

f Inlah 


Hgure  1 1 :  Text  Hie  Description  of  Stop-and-Wait  protocol 


The  adjacency  list  for  foe  stop-and-wait  protocol  is  depicted  in  its  structural  form  in 


Hguie  12.  This  adjacency  list  is  used  for  constructing  the  global  reachability  graph.  The  adjacency 


list  contains  all  the  necessary  information  for  goierating  the  global  teachability  graph. 


Machine  1 


Machine  2 


Hgute  12 :  Adjacency  list  for  foe  example  Stop-and-Wait  protocol 
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3.  Reachability  Analysis 


After  reading  the  ii^t  file  the  program  goierates  the  global  readiability  grqih.  Ituies 
the  adjacency  list  and  the  initial  state  to  begin  OMistniction  die  global  leadiability  Starting 
with  the  initial  state  new  states  are  genmated  and  compared  with  previous  cues  based  mt  didr 
reflective  index  value.  The  global  reachability  graidi  construcdmi  algoridim  is  given  in  Figure  13. 
loop  (main  loop) 

for  indexl  in  1 ..  total  numberjfjnachines  loop 
place  holderiindexl) mdemie  array(indexlXMstate(indexl)) 
whilelplace_holder(index)  /«  ntdf)  loop 
loop 

if(placeJiolder(indexl).transition  s  s)  then 
Enqueue  the  message  into  the  corresponding  message  queue 
search  hash  look-up  table  for  this  global  state  tuple 
slot  of  the  hash  look-up  table  was  not  set  then 
This  is  assumed  to  be  a  new  state  set  the  slot  and  create  a  new  state 
Enqueue  this  new  node  to  the  pointer_queue 
else 

print  out  the  transition  and  discard  the  tuple 
end  if 
else 

tf  (place_holder(indexl  ).trmsition)  »  r  and  at  least  one  of  the  message  queues  for 
this  machine  is  not  empty  then 
find  this  message  queue  and  Dequeue 
search  hash  look-up  udtle  for  tfUs  new  global  state  tuple 
If  slot  of  the  hash  look-tq>  table  was  not  set  then 
This  is  assumed  to  be  a  new  state  set  the  slot  and  create  a  new  node 
Enqueue  this  new  node  to  the  pointer  queue 
else 

print  out  the  transition  and  ttiscard  the  tuple 
endf 
endf 
endf 

place_holder(indexl)  ;= place_holder(indexl).Slink 
exit;  ~ 
end  loop 
end  loop 

if  pointer jiueue  enqtty  then 
exit  ~ 
else 

Dequeue  pointer  queue  and  update  M_state  for  this  new  node 
endf 

end  loop  (mam  loop) 


Hgure  13  :  Algorithm  for  Generating  Global  Reachability  Gra{di  for  CFSM 


During  the  gnyih  construction,  the  program  also  detects  the  global  states  with  dead  lodts 
or  unspecified  receptions.  The  program  also  rinds  the  maximiim  message  queue  size  and  channel 
overflows.  Analysis  results  are  stored  in  an  output  file.  This  avoids  the  need  to  transverse  the  entire 
grafh  an  additional  time  at  the  end  of  the  program.  Program  run  time  is  thus  dramatically  reduced. 
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One  of  ttie  most  time  consuming  {noceduies  is  the  search  algorithm  used  to  detect  if  a 
state  was  previously  created  The  previous  versimi  of  dds  prognun  used  open  hashing  to  seardi 

throughdie  previously  created  global  states.  All  states  were  ki^  in  a  linked  list  associated  whhdieir 
hash  index.  For  the  analysis  of  small  inotoools  diis  is  not  a  problem.  The  search  is  fut.  the  memoiy 
required  is  small,  and  the  linked  lists  are  short.  The  analysis  of  larger  protocols,  liidc  lists  grows 
Itmger  due  to  increased  hash  conflicts  and  die  applicability  of  regular  mushromn  becmnes 
restricted. 

With  Supertrace  the  search  is  also  made  via  hash  function  but  utilizes  a  diffnent 
implementatioiL  First,  the  size  of  hash  table  is  determined  based  iqwn  die  expected  numtm  of  die 
states  generated  to  oisuie  adequate  coverage,  but  is  limited  by  the  availability  of  memory.  Second 
the  hash  function  uses  die  machine  states  and  the  messages  on  die  queues  between  the  machines  to 
provide  a  fast  and  efficient  mapping.  The  complexity  of  die  search  algoridim  is  always  0(1).  This 
is  obvious  when  the  hash  funcdon  generates  a  unique  index  (no  collision).  When  die  hash  fiincdon 
generates  the  same  index  for  two  different  states  Supertrace,  discards  the  new  state,  (as  a  duplicate) 
as  it  only  checks  if  the  hash  talde  slot  is  set(collusion)  or  not  set(new  state).  Previous  tuples  are  not 
compared.  This  makes  the  search  more  efficient  Because  we  are  using  a  voy  big  hash  table,  the 
hash  function  creates  a  distinct  index  (table  slot)  for  almost  every  global  state. 

The  effecdveness  of  die  Super  Trace  algoridim  dqiends  iqxm  the  rado  of  hash  table  size 
to  the  expected  number  of  states,  the  effectiveness  of  the  harii  funcfion  which  gmierates  the  indices 
for  the  hash  array.  The  hash  function  vriiich  generates  die  indices  for  protocols  specified  in  CFSM 
model  is  shown  in  Hgure  14. 

The  second  issue  that  has  effect  on  Supertrace  Algoridun’s  efficiency  is  the  available 
memory  on  die  system.  The  size  of  the  hash  table  must  be  as  big  as  possible  to  minimize  the  numbm^ 
of  hash  conflicts.  The  need  for  a  very  large  memory  can  1X4  be  overemphasized. 

The  impact  of  such  a  large  tatde  is  minimized  by  utilizing  the  Ada  Programming 
Language  predefined  pragma  “pack.”  The  pragma  “pack”  tells  that  storage  minimization  should  be 
main  criterion  for  ie{»esaiting  of  the  given  type  fiiash-lookup-table)  to  the  compiler.  By  using  that 
option,  boolean  types  which  normally  are  represented  as  1  byte  (8  bits)  in  die  monory;  can  be 
reduced  to  one  bit  vdiich  saves  sevoi  bits  per  byte.  We  can  effectively  increase  the  size  of  our  hash 
table  by  700%  without  using  additional  memory  space.  So  a  hash  table  of  size  1545278  is  used  in 
our  applications  without  using  big  part  of  memory. 

The  structure  of  a  global  state  is  shown  in  Figure  15.  The  maximum  number  of  outgoing 
transitions  is  artificially  limited  to  7.  It  can  be  increased  if  necessary.  A  maximum  diamiel  capacity 
of  6  messages  is  introduced  to  ensure  that  die  analysis  eventually  stops. 


21 


fiinctkm  ImA  (m :  in  iMchlnejKi^^ 

q :  queuejtype)  return  imeter  is 

index  :int^er^BO; 
sum  :  integer  :■  0; 
bMin 

for  i  in  1..8  loop 
for  i  in  1..8  loop 

if  iniBg^q(next_macliinejtype(i),next jnacliine_typeO))-iail)  Hi  dten 
for  1  in  l..int^er(q(next_niachiiie_ty^i)4)ext_niacliine_9^')).tail)  loop 
forkin  1.3  loop 

sirni  :Bsum4chaiaciBt'pos(q(nexcnuidiinejtype(i)  jiextjn8CliinejtypeQ)).siore(l)0r))*^ 
end  loop; 
endkxm; 
end  if; 
end  loop; 
end  loop; 

index  >  (integer(in(8))*1976S>Kintega  (m(7))*2978)  +  (imMer(m(6))*  43270) 

+<imegcr  (m(5))* 13791)  +  (integer(in(4))*  28433)  4^ger(in(3))*  17237) 

■Kintegcr  (in(2))*  37777)  +  (integer(in(l))*  635799); 
letum  ((index-fsumM)niod  30S4M23); 
end  hash; 


Hgure  14 :  Example  Hash  Function  For  Stop-and-wait  Protoctd 


Hgute  IS  :  Global  State  Stnictuie  with  outgoing  transitions 
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4.  Output 

The  prognun  stores  the  analysis  results  in  a  file  named  by  tfie  user  during  the  readiability 
graph  constracdoa  The  file  contains  the  specification  in  a  tabular  fonnat,  die  readiabUity  gr^  and 
the  results  of  die  analysis.  The  analysis  results  amsists  of  six  separate  sections.  They  are  die  number 
of  states  generated,  number  of  states  analyzed,  number  of  deadlodcs  detected,  number  of 
unspecified  recqitions  detected,  maximum  message  queue  size  and  the  number  of  diannel 
oveiflows.  Global  states  with  deadlocks  and  unspecified  receptions  are  also  maiked  in  die 
reachalnlity  gn^h.  The  ouqmt  file  also  lists  any  unexecuted  transitirais. 

The  program  ouqwt  for  the  imaginary  protocol  in  Qiapter  n  is  listed  in  Hgure  1 6.  Since 
no  states  are  stored,  in  case  of  a  collision  we  can  not  determine  whether  it  is  a  hash  conflict  of  a  new 
state  or  a  duplicate  state.  These  states  are  refoied  as  0  in  the  output  file.  For  example.  In  our 
example  protocol  after  state  8  “-fdl”  transition  is  taken  vriiich  leads  to  state  1.  Since  program 
doesn’t  keep  state  1  it  will  just  ouqxit  0  for  the  duplicate  state. 

C.  Big  Mushroom  With  Supertrace 

In  this  section,  die  program  that  automates  the  full  global  analysis  (big  mushroom)  for  a 
protocol  specified  by  a  SCM  is  model  described.  The  description  of  the  program  is  divided  into  four 
sections:  general  program  stracture,  irqruts  to  the  program,  generating  the  readialxlity  grtqdi,  and 
ouqxits  of  the  program.  Since  the  smart  mushroom  program  mentioned  in  Chapter  n  generates  a 
relatively  small  number  of  states  it  is  considered  outside  the  scope  of  this  thesis  and  will  not  be 
moitioned  in  the  following  sections. 

1.  Program  Structure 

Program  structure  of  Big  mushroom  is  similar  to  the  structure  of  Simple  Mushroom.  The 
SCM  model  specification  is  mote  complicated  than  the  CFSM  specification,  but  this  complexity  in 
the  specification  brings  some  advantages  to  the  analysis  as  mentioned  in  Charter  n.  A  protocol 
specified  by  the  SCM  iBodel  consists  of  FSMs,  variable  definitions,  and  predicate-action  table, 
rather  than  just  the  FSM$  as  in  CFSM  model. 

FSMs  ate  entered  into  the  program  in  the  same  maruier  as  in  the  Simple  Mushroom 
program  using  a  text  file.  The  variable  definitions  and  predicate-action  table  must  also  be  altered 
into  the  program.  The  user  enters  these  parts  by  completing  Ada  padcages  and  subprograms  using 
the  templates  provided. 

The  compilation  units  for  the  program  are  shown  in  Table  3.  The  user  has  access  to  tiie 
last  four  padcages/sulqirogtams.  Once  the  user  completes  these  programs  using  the  templates  arxl 
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RBACHABILirr  tUKUtaiS  of  I  aacuvlo.fn 

sracxrzcATZoN 


1 

Nadiine 

1  State  Transitions 

1 

1  Pros) 

1  To 

1  other  machlna  1  Transition  1 

1  1 

1  2 

12  Is 

dO  1 

1  1 

1  3 

12  Is 

d3  1 

1  2 

1  1 

13  1  r 

d2  1 

1 

Machine 

2  State  Transitions 

1 

1  From 

1  To 

1  ocher  madilne  1  Transition  1 

1  1 

1  2 

11  1  r 

dO  1 

1  1 

1  3 

11  1  r 

d3  1 

1  2 

1  1 

13  Is 

dl  1 

Machlno  3  State  Transitions  I 


I  From  I  TO  I  other  machine  I  Transition  I 


I  1  I  2  I  2  I  r  dl  I 

I  2  I  1  I  1  I  8  d2  I 

I  2  I  3  I  1  I  s  d4  I 


REACHABILITY  GRAPH 

1  {  l.E,E,  l.E.B.  1,E,E] 

-do  2  (  2. do  ,E,  l.E.E,  1,E,E)  2 
-d3  2  (  3.d3  ,E,  l.E.E,  l.E.E)  3 

2  (  2,d0  .E.  l.E.E,  l.E.E] 

'fdO  1  (  2.E,E,  2.E,E,  l.E.E)  4 

3  (  3,d3  ,E.  l.E.E,  l.E.E] 

+d3  1  (  3,E,E,  3,E.E.  l.E.E)  S 

4  (  2.E.E,  2,E,E,  l.E.E] 

-dl  3  (  2.E,E.  l.E.dl  ,  l.E.E)  6 

5  (  3,E,E,  3,E,E.  1, E.E) ••••••••**DEAiaX)aC  condition* 

6  (  2,E.E,  l.E.dl  ,  l.E.E] 

>dl  2  [  2,E,E,  l.E.E.  2,E.E)  7 

7  (  2,E.E,  l.E.E,  2,E,E) 

-d2  1  (  2,E.E,  l.E.E.  I.d2  .E]  8 
-d4  1  (  2.E,E,  l.E.E.  3,d4  ,E]  9 

8  (  2,E,E,  l.E.E.  I,d2  .E] 

>dZ  3  [  l.E.E,  l.E.E.  l.E.E)  0 

9  [  2,E,E,  l.E.E,  3,d4  ,E) **********Unspeclfied  Reception’ 

SUMMARY  OF  REACHABILITY  ANALYSIS  (ANALYSIS  COMPLETED) 


Total  nnmlser  of  states  generated  :  9 
Nusiber  of  states  analyzed  :  9 
number  of  deadlocks  :  1 
nundser  of  unspecified  receptions  :  1 
maximum  message  queue  size  :  1 

channel  overflow  :N(WE 

UNEXECUTED  TRANSITIONS 

••••♦NONE***** 

Hgure  16 :  Program  Output  for  the  example  protocol 
compiles  them  wifli  the  other  compilation  units,  the  analysis  of  flie  spedhed  protocol  can  be 
perfoimed.  Construction  of  the  specification  in  the  form  of  Ada  padtages  and  subprograms  is 
explained  in  die  next  sectioa 
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TABLE  3:  BIO  MUSHROOM  PROGRAM  COMPILATION  UNITS 


ComiMlitionUiitt 

Deaoqitkm 

Rlebbune 

main(prooedare) 

This  is  the  poTMi  iiiur.  Coniaint  the  maia 
data  stnictures.  ^obai  variable 
and  the  driver: 

Ic»d_iiUK:liine_ani^ 

(procedure) 

Buihb  the  adjacency  fists  firem  FSMs. 

suqtoLa 

read_inJUe(procediire) 

Fatses  the  inpin  FSM  text  file 

siiqNiLa 

biiildjOstate_gra|)h 

Oiuocediire) 

Generates  the  global  reachability  graph. 

sgjreachabilityjk 

GlobaLhash(fiiiiction) 

Generates  an  index  number  according  to  the 
Supeilkaoe  hashing  fimctionforBig 
nunhioom. 

sgjeachabili^x 

hash(funcdon) 

Generates  an  uidex  number  according  to  the 
hashing  function  for  Smart  mushroom  option 

sg^jeachabiltyji 

clear_poinicR(procedure) 

Deallocates  the  dynamic  memory  space  for 
another  analysis 

sg_reachabiltya 

search.for_Stiqrie 

(fiinctim) 

Searchs  the  leachabifiQr  graph  for  the 
equivalent  system  tiqiltt  usmg  hashing 

sg.seaichx 

c]ear_hs_hash_anay 

(procedure) 

Clears  the  hash  army  and  deallocates  the 
memory  for  sysiren  stme  analysis 

sgjsearclut 

ooqN^jGstaie.node 

(procedure) 

Ouqmts  the  machine  states,  and  the  stales 
widi  deadlodcs  for  global  reachability 
analysis. 

sgjouqtuta 

output^sys.node 

Qirocedure) 

Outputs  machine  states,  and  states  with 
deadlocks  for  system  stare  analysis. 

sgjoutputa 

ouqwt_GsiaiB_iiansition 

(procedure) 

Outputs  the  transition  name  for  global 
readability  analysis. 

sgjouqmta 

ouqwcsysjtiansition 

Quocedure) 

Oubmts  the  transition  name  for  system  state 
analysis 

sgjouqut 

ouipiiL.uiiexecuted_tiaiisitioiis 

Qxocedure) 

Outputs  the  unexecuted  transitians 

sgjouqwta 

ouQNit.machine.anays 

Outputs  the  FSM  description  in  a  tabular 
format 

sgjoutputa 

ouqwcanalysisOirocedure) 

Driver  for  the  output  subprograms 

sgjouqwta 

CRatBjoutput_fik  (procedure) 

Creates  an  ouqiut  file  for  storing  the  analysis 
results 

sgjoutputa 

systein_call(procedure) 

Interface  procedure  fix  Unix  system  calls  via 
C. 

ssystema 

queues(generic  package) 

In^lements  the  qureie  iterations  for  the 
pomter  queue  that  stores  the  nodes 
temporarily. 

squeuesa 

stacks  (generic  package) 

Implements  the  stack  operation  for  storing 
enabled  transition 

sstacksa 

definitions  (package) 

Includes  user  defined  local  and  shared 
variables 

named  by  the  user 

Analyze_nnedicatBs  (procedure] 
three  is  one  for  each  machine 

Determines  the  enabled  transitions  firom  the 
predicates 

named  by  the  user 

TABLE  3:  BIO  MUSHROOM  PROGRAM  COMPILATION  UNITS 


CompilaiionUiiit 

Deacr^doa 

FOeName 

Action  procedure) 

Executes  the  actions  Sorthe  enaUed 
Innsitions. 

ouiput_gtuiiie  (procedure) 

(hiiputs  the  global  state  ngdes  in  a  fonnst 
defined  by  the  user. 

named  by  the  user 

2.  Biput 


The  inputs  to  the  program  consists  of  fliree  puts,  as  nienti<med  eariio’.  FSMs  are  entered 
using  a  text  file  lefnesentation  as  in  Simple  Mushroom  program.  VariaUes  and  {xedicate-actioa 
table  are  entered  as  Ada  padcages/subprograms.  The  user  needs  to  complete  these  packages  and 
subprograms  by  filling  in  tempiates  provided. 

The  Ada  package  for  the  variable  dedaratkms  is  called  **ddlnitkms.”  The 

predicate-action  table  is  entered  using  an  Ada  subprogram  template  whidi  consists  of  one  procedure 
named  “Action”  and  two  to  eight  procedures  called  “Analjze_Prcdicate_Macliine*”  according  to 
the  number  of  machines  in  die  protocol.  The  at  die  end  of  the  procedure  name  is  re{daced  by  die 
conesponding  machine  number  for  each  machine  in  the  protocol. 

After  completing  the  templates  desoibed  above,  die  user  must  cmnpile  these  units  with 
the  other  compilation  units  listed  in  Table  3.  Since  the  comidetimi  of  diese  was  exidained  in 
[BIJLB93],  diey  will  not  described  here.  But  our  example  iHOtocol  stop-and-wait  in  Clu^r  n  is 
used  to  Ulustrate  how  to  complete  the  templates. 

a.  Finite  State  Machines 

There  are  afew  di^rences  in  die  FSM  description  of  Big  MusAromn  progtam  frcmi 
Simple  Mushroom  program.  In  die  SCM  model,  explicit  machine  numbers  to  show  udiich  machine 
the  message  sent  to  or  received  from  are  not  needed  for  die  transition  names.  Since  riuued  variables 
are  used  for  communication  between  machines,  this  infonnation  is  induded  in  die  predicate-action 
table.  The  FSM  text  file  for  die  example  ring  protocol  is  shown  in  Figure  17. 

The  FSM  text  file  is  read  by  the  ii^xit  procedures  and  die  adjacency  list,  vdiich  is 
used  during  the  constniction  of  system  and  global  reachalnlity  gn^  is  generated. 

b.  Variable  Definitions 

The  user  defines  the  protocol  variables  in  Ada  package  named  definitions.  This 
package  includes  the  local  variables  for  eadi  madiine  and  the  global  variables,  idiich  are 
considered  shared  and  allow  communication  bdween  machines.  A  variable  can  be  one  of  die  Ada 
defined  types  such  as:  integer,  array,  string,  record,  character,  boolean  etc.  These  types  and  dieir 
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■care 

niialMr_of_iaachln«a  3 
Mchln*  1 

acac*  0 

trana  SndLdaca  2 

acata  1 

trana  Rcv_Ack  2 
■achlna  2 
acata  0 

trana  Rcv_daca 
acata  1 

trana  Sn^Jick 
Inlclal.atata  0  0 
flnlah 


Figure  17 :  Text  file  desciipti<xi  of  the  examine  ring  protood 
subtypes  are  used  to  define  die  protocol  variaMes.  The  variaMe  declaration  for  the  stop-and-wait 
protocol  is  shown  in  Hgure  18. 

e.  Pndieate-AetioH  Table 

The  predicate-action  tatde  is  rq;)resented  by  a  number  of  subprograms  as  sqwrate 
compiladon  units.  These  subfnograms  are  tamciAmUyze-Predicates  and  are  used  to  determine  the 
enabled  transitions  for  each  madiine.  The  i»Dcedure  named  Action  executes  the  actions  to  be  taken 
for  the  corresponding  enabled  predicates.  There  is  one  Analy2e_Predicates  procedure  for  eadi 
madiine  and  one  Action  procedure  for  the  protocol.The  user  comidetes  die  temphrie  fiir  each  state 
of  the  machines.  The  piedicate-acdmi  file  for  die  example  stop-and-wait  protocol  is  shown  in 
Figure  19. 

The  enabled  transitions  are  passed  into  this  procedure  duough  die  “injransition” 
formal  parameter  and  the  necessary  changes  are  made  to  the  local  and  dialed  variaUes  by  the  Acrfon 
procedure.  The  “out.system_state”paiameter  passes  the  dianged  protocol  variables  to  the  calling 
procedure.  The  completed  Actitm  procedure  is  shown  in  Hgure  20.  Text  in  boldface  shows  die  user 
defined  parts. 
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wttlEXrjO; 

omIEXTJ^ 

PBBSMO  OBIbODOIIB  V 

naauoOMddaes :  oomant  >  2: 

type  fcnijnniiiioajtype  k  CSad^data,  Rcv^dala,  Sadjlck,  Kcv_Ack,  WMid); 
type  bofbr  MW  k  (D,A^ 

peHagelNiaLeiMni_iok  new  eonmeatkm Jo  (buffer  type); 

uwb^enum_io; 

type  {hanmyjtype  k  range  l.^S; 

type  machinel  jnaiB.type  k 
leconl 

oat_baff  :  baffer_type :»  D; 
endiecocd; 

type  nucliiiie2 jttate.type  k 
tecofd 

tnjwff :  bufifer.type E; 
endfecofd; 

type  niacliine3_state_type  k 
lecofd 

dummy :  dummyjtype; 
endieoocd; 


type  machine8_staiB_type  k 
tecotd 

dummy :  dummyjtype; 
endiecocd; 

the  globaLvariaUejtype  k 
tecoid 

CHAN :  buffiaj^pe  :aiE; 
RET  :  buffojtype  :s  E; 
endieoonl; 

end  dilutions; 


Figure  18 :  Craipleted  Definitions  package  for  stop-and-wait  protocol 
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sqMBMB  (maio) 

pncedim  AMlyze_Pi«dicates_MachiiielOocal :  macbineljEiatBjQ^ 

GLOBAL:  glotaLvarUble.type; 
s  rnansal;  w :  in  ottt  itM8kk)o_a«ackjadnige.sttfJf)  is 

bq{in 

casesis 

wkcnOa> 

if  ((GLOBAL.CHAN  s  E)  and  (LOCAUwt.bnir/s  E))  dien 
PuslKwjSiidjIata); 
endift 

whanls> 

if  (GLOBALJIET  s  A)  then 
Push(wjtcv  Ack); 
endif; 

whenotfien«o 

null; 
end  case; 

end  Analyze JPKdkates.Machinel; 

procedure  Analyre Jh»dk»aBs31acliine2(local :  inachine2_staie jtype; 

GLOBAL:  gk)bal_variable_type; 
s  :  natural ;  w :  in  out  transition_stack_package.stack)  is 

begin 

casesis 

whenO=> 

if  (GLOB  AUCHAN  /=  E)  then 
Push(w^cv  data); 
endif, 
wlienlB> 
if  true  then 
Push(w,Snd  Ack); 
endif; 

when  others  a> 
null; 
end  case; 

end  Analyze_Predicate8_Machine2; 

procedure  Analyze_Predicates_Machine3(local :  machines jstatejype; 

GLOBAL:  global_variable_type; 
s  :naniral;  w :  in  out  transition_stack_package.stack)  is 

b^in 

null; 

end  Analyze_PRdicates_Madiiiie3; 


procedure  Analyze_FredicatBS_Machine8(local :  niachine8_state_type; 

GLOBAL;  global.vaiiable.^pe; 
s  : natural;  w;inouttransition_stackj;nckage.stack)is 

begin 

null; 

end  Analyze_Predicates_Machine8; 

Hgure  19 :  Completed  Analyze_Predicates  procedures  for  the  Stop-and-wait  protocol 
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sqiame  (main) 

IKOcedine  ActioiiOn_iytieaajnnB:  in  out  OAaie_feooRL9pn: 

in_aanntion :  in  am  scmjnnsitiaa jty^ 
onLsysiemjnaiB :  inuomG8am_;ecoirdLqrpe )  is 

b^in 

case  (ini_Kaiisition)  is 
wliea(SBd  datn)a^ 

ouOtystm_staie.GL(niAL_VABIABLES.CIIAN:>  inj8ysttmjttaiejmacliinelj5taie4Wt_bnllt 
0ut_syslBmjnaiBJnacliinel3t8iBmit_bnfr :»  E; 
when  (Rev  datn)*^ 

0iUjwsira«_staiejnachine2_staieJnJbnff  >  injqfaieanjBaie.GLOBAL_VARIABLES.CHAN; 
when  (^_Ack)  •£> 

0iMLsystNn_statB.GLOBAL_VARIABLESJtET  >  A; 
out_systBm_statB.machine2_JtateJn_bnff  >  E; 
when  (Rcv_Ack)  ■> 

outjiystm_stalB.GLOBAL  VARIABLES.CHAN;«  E; 
outjsystBmjstat6.GLOBAL2VARlABLES  JtET  >  E; 
when  othen  ^  piit_liiie(*rhere  is  an  CRor  in  the  Action  procedine"); 
end  case; 
end  Action 


Hgure  20 :  Completed  Action  piocedaie  for  die  Stop-md-Wait  protocol 
3.  Global  Reachabilitj  Analysis 

The  process  of  generating  and  examining  the  set  of  all  reachable  states  fiom  the  initial 
state  is  called  reachability  analysis.  The  program  is  c^iable  of  generating  bodi  the  global  and 
system  reachability  analyses  separately  for  a  protocol  formally  specified  by  the  SCM  model.  Since 
the  system  reachability  analysis  generates  relatively  small  number  of  states  Svpeitiace  Algorithm 
is  not  used  for  that  analysis. 

The  user  can  select  eidier  global  reachability  analysis  or  system  state  analysis  from  a 
menu.  During  the  gnqdi  construction,  the  program  also  detects  any  deadlock  cmiditions.  Aruilysis 
results  are  stored  in  an  outyut  file  named  **rgraidLdat”  in  parallel  with  graph  construction. 

The  structure  of  the  global  state  used  for  the  program  is  shown  in  Hgure  21.  This  tKxle 
structure  also  includes  outgoing  transitions.  The  maximum  number  of  outgoing  transitions  is 
artificially  limited  to  7.  It  can  be  increased  as  necessary.  The  shared  variables  are  stored  in  the 
"globalj/ariables”  variable  and  local  variables  are  stored  separately  for  each  machine  in 
“machine _stat^”  variables. 
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GTUPLE 

MacUMjTOUe 

DsaassBEi 

dMwl_variaM« 

nachiMljUate 
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• 

1 

1 

LINK 

1 

2 
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• 

• 

• 

i 

Figure  21 :  Global  State  Stnicture  with  Outgoing  Transilions 


Hie  initial  global  state  is  created  fiom  both  the  FSM  text  file  and  the  initial  values  of  die 
variables  assigned  in  the  definitiais  package.  AU  the  outgoing  tnuisitions  are  initially  set  to  null. 
Starting  with  the  initial  global  state,  new  nodes  are  added  and  linked  to  die  gra{h.  The  pseudo-code 
algorithm  for  constructing  the  global  reachability  gttydi  is  shown  in  Hgure  22. 

The  program  implements  hashing  to  search  duDugh  hash  table  for  duplicate  states  udiich 
increases  the  run  time  efficioicy  of  the  analysis.  There  is  a  major  difference  between  the  Simple 
mushroom  and  the  Big  mushroom  hashing  functions,  hi  die  Simple  mushroom  program  the  user 
does  not  need  to  specify  a  hashing  function.  A  predetennined  function  \riiich  considms  marhiiv» 
states  and  message  queues  is  implemented  in  the  program.  For  thefiig  mushroom  program  die  usct 
must  design  and  enter  a  global  hashing  function.  The  function  must  account  for  machine  states, 
local,  and  global  variables.  An  example  of  a  global  hash  function  for  Stop-and-wait  protocol  is 
given  in  Figure  23. 


4.  Output 

The  program  stores  the  results  of  the  analysis  in  a  file  named  “i:gr!qh.dat”  This  file 
contains  FSMs  in  a  tabular  format,  system/global  reachability  gnqih,  and  die  results  of  analysis 
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UH^mainioop) 

fi^imkxl  bil ..  total  nmtarjf  machines  loop 
position  hoUer(in£xJ)  :*  maehinejjrray(ituiadXht  tutufindexl)) 

DeternAe  the  enabled  transiHons for  the  maehine( indexl )  and  push  into  transitkmjttack 
While  not  EmptyltranMonjtadc)  loop 
while  (posUtonJiolderiiiulexl)  /■  ludl)  loop 
Trawrse  thelnaehine  arrays  for  each  enabled  transition  in  the  stack 
if  a  transition  finmd  in  the  machine  arrays 
create  a  temporary  node  resuidngfrom  this  transidon 

coil  Action  ^cedure  to  make  the  necessary  changes  to  the  varUAles  of  this  node 
Search  the  Hash  look-up  ubie  to  see  this  node  was  created(redundant) 

If  the  table  slot  corresponding  to  the  index  created  by  hashjunction  is  not  set(faise)  then 
set  the  table  sbt(true) 

Enqueue  the  no^  into  the  Gpointerjpieue 
else 

write  transition  to  the  output  file  and  discard  the  node 
endtf 
else 

position  holder(indexJ) :»  position_holdeiiindexl)Slink 
end^ 
end  loop 

ifttot  Empty(traHsition_stack)  and  a  transition  not  found  in  the  machine  arrays 
p<q>  the  stack  ~ 
eiuif 
end  loop 
end  loop 

IfGpointerjjueue  Empty  then 
fxit 
else 

Dequeue  Gpointerjpuue 
Upikae  Mstate  forlhis  new  node 
endtf 

end  loop  (main  loop) 

Hgure  22 :  Algoiidun  for  Generating  Global  Reachability  Graph  for  Big  Mushroom 

function  GLOBAL_HASH  ( cuirent_gstaiB :  Gstate_iecocd_type)  return  integer  is 
index:  integenaO; 
sum:int^a:aO; 

m :  niaclune_state_anay  current_gstatB.niachine..statB; 
begin 

index  .•=  ( (m(8)  *83999)  +  (  ni(7)  •  72888)  +  (in(6)  *61997)  +  (m(5)  *5995)  + 

(in(4)  *  46571)  +(m(3)  *  34677)  +  (in(2)  *  21323)  +  (m(l)  *18203)  ) ; 
sum  :s  bufrerjt^t>os(cunent_^^«iejnachinel_state^_bu£f)*373351-i' 
buffer_t^'l^cuiient_gstaiejnachine2_statBjnJbu£f)*^77139f 
buffcr_type'pos(current_gsiate.GLOBAL_VARIABLK.CHAN)*973551+ 
buffer_type'pos(curmit_gstatB.GLOB  AL_VARIABLESRET)* 12355 1 ; 
return  ((indra(*3-Kum*7)  nuxl  1545423); 
endGLOBAL_HASH; 

Figure  23  :  Global  Hash  function  for  Stop-and-wait  protocol 
consisting  of  number  of  states  generated,  number  of  states  analyzed,  and  number  of  deadlodcs. 

Unexecuted  transitions  are  also  listed  at  the  end  of  the  analysis. 

Since  each  protocol  specification  has  differmt  variables,  the  user  also  has  the  flexibility 
to  outyut  the  desired  variables.  This  is  done  in  a  similar  manner  to  the  predicate-action  table  and 
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variaUe  definitions  iq»esentation  exjriained  in  [Bl)LB93]  using  an  Ada  procedure  iMpipiwm*  Th». 
user  ccunpletes  the  template  with  Ada  “put”  statements  for  outputting  die  glotiai  states.  Since  die 
system  state  tuples  do  not  include  the  variables,  there  is  no  need  to  define  an  output  format  for 
system  reachability  graph.  The  complied  template  for  the  output_Gtuple  procedure  for  stof^and- 
wait  protocol  is  also  given  in  Figure  24. 
squrate  (main) 

procedure  ouqiut.Giuple  (tuple :  in  out  GstatB_iecoid  type)  is 
begin 

if  print_beader  dien 
new_line(2): 
setjcoKS); 

put_Une  ("  ml(out_buff)4n2(in_buff),  (CHAN.  RET)*); 
iniiit_header false; 
else 

put(”  [''&integer’image(tuplejnachuie  state(l)) ); 
put(","); 

buff_enum_io.put(tuple.niachinel_statB.out_bu£0: 

put(","); 

putC  ["&integer‘image(tuplejnachine  state(2))); 
put(",’); 

bofr_enum_io.put(tuple.machinel  statein  buff); 

MV);  ■  ■ 

buff_cnum_io.put(tuple.GLOBAL  VARIABLES.CHAN); 

l)uff_er>um.!0.put(tuple.GLOBAL  VARIABLESJtET); 
put(-l-); 
end  if; 

end  output_Gtuple; 


Hgure  24 :  (Completed  oufout.Gtuple  procedure  for  Stop-and>walt  protocol 
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The  ou^wt  of  program  for  the  exanqile  ring  pioloMd  is  given  in  Flgare  25. 

RBACHABILITY  ANALYSIS  of  laCopwalC.aca 
SPBCIFXCATION 


1  Nachino  1  staco  Tranaltlona  1 

1  From  1  To  1 

1  Tranaicion  1 

1  0  1  1  1 
1  1  1  0  1 

1  sn4_daca  1 

1  rcv_aclc  1 

1  Machlna 

2  SCata  Tranaltlona  1 

1  From  1 

TO 

1  Tranaicion  1 

1  0  1 

1 

1  rcv_daca  1 

1  1  1 

0 

1  and-ack  I 

REACHABILITY 

GRAPH 

oucjsuff  , 

m2  , 

InjMlff,  CHAN,  RET 

0 

( 

0 

D  . 

0  . 

E  . 

E  . 

E  ] 

and_daca 

1 

1 

( 

1 

D  . 

0  . 

E  , 

D  . 

E  ] 

rcv_data 

2 

2 

[ 

1 

D  . 

1  . 

D  . 

D  . 

E  ] 

snd_ac]c 

3 

3 

( 

1 

D  . 

0  . 

D  . 

D  . 

A  ) 

rcv_acJt 

0 

SUMMARY  OF  REACHABILITY  ANALYSIS  (ANALYSIS  COMPLETED) 


Number  of  acates  generated  :4 
Number  of  acates  analyzed  :4 
Number  of  deadloclcs  :  0 


UNEXECUTED  TRANSITIONS 

•♦•••NCaiE***** 


Hgure  25  :  The  Output  of  foe  Program  for  the  Examide  Ring  Protocol 


D.  Summary 

In  this  ctu^r,  example  protocols  in  Chapter  n  were  analyzed  to  dononstrate  the  usage  of 
Mushroom  program.  The  protocols  analyzed  in  this  chapter  are  intentionally  chosen  simple  to  help 
the  user  understand  foe  mushroom  program’s  iiqxits  and  outputs.  However,  the  analysis  results 
verifies  that  Supeitrace  algorithm  approximates  the  foil  search  mefood  by  generating  the  same 
oufouts  obtained  manually  in  Chapter  n.  The  major  achievemem  of  Supeitrace  wiU  be  illustrated  in 
Chapter  V  with  larger  protocols. 
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IV.  A  PROGRAM  FOR  PROTOCOL  TEST  SEQUENCE  GENERATION 


In  ttiis  duptn*.  the  concqit  of  confoimance  testing  is  iiist  introduced;  nul,  a  procedure 
created  for  test  sequence  generatim  [LUND90A]  is  discussed.  Finally,  ‘TESTGEN,”  die  program 
which  automates  the  test  sequence  generation  is  illustrated. 

A.  Introduction  To  Conformance  Testing 

A  confoimance  test  is  used  to  ensure  diat  the  external  behavior  of  an  implementatirMi  of  a 
protocol  is  equivalent  to  its  fonnal  specification.  In  conducting  a  confoimance  test  we  are  given  a 
known  protocol  spedficadon  and  an  unknown  imidementation.  The  implemoitatiCHi,  for  practical 
purposes,  is  considered  as  a  black  box  with  a  finite  set  of  iiqiuts  and  outputs.  The  test  provides  a 
sequence  of  iiqxit  signals,  and  observes  the  resulting  ouqmts.  The  implementation  under  test  (lUT) 
should  pass  the  test  only  if  all  observed  outputs  match  those  prescribed  by  the  formal  qwdficatioiL 
The  series  of  input  sequences  which  are  used  to  exercise  the  protocol  implementation  in  this  way 
are  referred  as  cortformance  test  sequence  throughout  this  diesis. 

Two  problems  with  conformance  testing  need  to  be  solved: 

1.  Rnd  a  general,  tqiplicable,  efficient  procedure  for  generating  a  confoimance  test  sequence 
for  a  given  protocol  implementation,  and 

2.  Find  a  method  for  applying  tin  test  seqt^ice  to  a  luraiii^  implementation. 

This  first  issue  is  the  focus  of  this  thesis  while  the  second  problem  is  beyond  the  scope  of  diis 
thesis. 

It  is  desirable  to  have  the  specification  of  a  protocol  expressed  in  a  formal  mottel  and  the 
specification  formally  verified. 

A  previous  study  [MILL90]  on  this  issue  observed  gaps  between  the  specification,  the 
verification,  and  the  confoimance  testing  of  network  protocols.  Protocol  models  whidi  are  designed 
for  specification  purposes  usually  have  many  powerful  program  language  constructs,  to  simplify 
the  specification,  but  are  difficult  to  analyze.  Protocol  models  designed  primarily  for  analysis 
purposes,  such  as  the  CFSM  model,  are  often  too  simj^e  for  the  specification  of  modem,  complex 
protocols.  Much  recent  work  on  confoimance  testing  starts  from  the  description  of  a  protocol  as  an 
incompletely  specified  finite  state  machine  with  iiqxit/output  labels  on  tiie 
transitions[CHEN90][DAHB90].  Nonnally  protocol  specifications  are  not  described  in  ttiis 
manner. 

Suppose  a  test  designer  was  to  design  a  test  for  a  protocol  specified  using  tiie  formal  language 
LOTOS.  First,  he  must  translate  tiie  specification  to  an  I/O  diagram.  This  is  a  difficult  and  complex 
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process,  nd  dning  iiMch  enon  are  easfly  iittio(hiced.  Only  then,  when  this  tnnslatim 
can  he  b^in  to  genenie  the  tests  for  confonnsnce  testing. 

The  automation  of  tiie  test  sequence  generation  [LUND90A]  is  an  attonpt  to  dose  tiie  gig) 
between  spedlicationA^eiification  and  testing  of  protocols.  In  tills  tiiesis,  tiie  test  generation  starts 
from  a  protocol  model,  designed  for  tiie  specification  and  verification  of  protocols.  A  procedure 
created  in  [LUND90B],  is  used  for  the  generation  of  a  test  sequence  for  a  protocol  qiedfied  in  tiie 
SCM  modd.  This  pnocedure  and  its  automatimi  as  a  software  tool  does  not  guarantee  tiiat  all  tiie 
errors  or  combination  of  errors  in  a  protocol  are  found.  But  they  do  iqiresait  an  attempt  to  exercise 
all  parts  of  protocols  providing  some  assurance  that  the  implementation  meets  its  purpose. 

B.  Test  Generation  Procedure 

In  tills  section  a  procedure  and  its  automation  are  described  for  generating  a  sequence  of  tests 
for  a  protocol  specified  as  a  SCM  model.  The  input  is  the  formal  protocol  spedfication  (FSM  and 
predicate-action  table)  specified  as  a  system  of  communicating  machines  (SCM).  The  oufout  is  a 
sequoice  of  tests  and  an  I/O  diagram  in  a  tabular  format  The  generated  sequence  is  intended  to  be 
qipiied  to  an  HIT. 

The  sample  lUT  throughout  this  section  is  tiie  network  node  for  CSMA/CD  protocol.  Bef(»e 
generating  the  sequence  of  tests  and  tiie  I/O  diagram  for  each  test  in  tiie  sequence,  shared  and  local 
variables  must  be  identified.  The  test  inputs  (the  shared  and  local  variaUes  that  can  be  set  in  a 
controlled  way)  and  the  ougiuts  (tiie  shared  and  local  variables  can  be  observed  for  test  purposes) 
should  be  identified.  These  irgiuts  and  outputs  form  the  I/O  for  the  test  steps. 

The  format  for  each  single  test  is 
^1,  ^2’  •••  »in  » ®2»  •••  >  ®in 

Si  is  the  state  of  machine  vdien  the  test  begins.  The  1 7,  <2, ...  ^  are  the  input  values  at  the  start 
of  test  executiorL  The  oj,  02, ...  ,o„9stiha  values  of  the  output  variables  after  test  execution.  Sg  is 
the  state  of  the  machine  when  the  test  is  compi^.  The  input  and  the  oufout  variables  are  tak«i  fiom 
the  shared  and  local  variables  of  the  machine.  The  determination  of  these  variables  is  expiained  in 
the  following  section. 

The  procedure  expiained  in  the  following  sections  is  taken  fiom  [LUND90A].  It  is  writtmi  in 
three  parts: 

•  Preliminary  steps, 

•  Test  sequence  generating  procedure,  and 

•  Refining  steps. 
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1.  PreUminary  Steps 


1.  From  ttw  madiine  spedflcattan  FSM  diagram,  maik  each  transition  whose  name 
appears  «i  more  than  one  transitiwL  Each  such  instance  for  a  ^ven  name  is  givoi  a  separate 
distinguishing  label. 

2.  From  ^predicate-action  tabie,  nme  the  number  of  clauses  in  each  enabling  predicate. 
Mark  each  clause.  An  enabling  predicate  may  consist  of  several  clauses,  any  one  of  uhich  might  be 
tnie,  allowing  the  transition  to  execute.  Marking  each  dause  insures  that  eadi  oat  is  tested 
individually. 

3.  For  each  shared  variable  x.  determine  if  x  is  an  input  variaUe,  an  ou^wt  variaUe,  or 
both.  For  each  x  which  is  both,  splitx  into  two  variables,  x,-  and  x^  for  testing  purposes. 

4.  For  each  local  variable  /.  determine  if  /  is  used  as  an  interface  to  foe  higher  layer  user 
of  this  protocol.  If  so  mark  /  as  ir^t,  oufout  or  bofo.  Each  such  local  variable  is  specifically 
designated,  and  is  an  input  variaUe  if  it  appears  in  an  enading  predicate,  and  an  ou^mt  variable  if 
it  rqpears  in  an  Action  part  of  predicate-action  tabie.  If  /  is  both  input  and  output,  sfdit  it  into  two 
variables  /,-  and  for  test  purposes. 

2.  Test  Sequence  Generating  Procedure 

Initially  foe  test  sequence  is  empty. 

1.  State  <-*  initial  state. 

2.  Let  r  s  (p/i)  be  an  untested  transition  from  state. 

(a)  Determine  foe  values  of  foe  irqnit  variables  which  make  exactly  one  of  foe  untested 
clauses  of  p  true.  Check  to  see  if  these  values  allow  any  other  transition  from  fois  state  to  be 
executed.  If  there  is  one,  set  additioruil  irqxit  variables  to  values  foat  insure  only  foe  tranation  under 
test  is  enabled.  Fill  these  in,  and  mark  ofoers  “DC”  for  “don’t  care.” 

(b)  Determine  and  mark  foe  expected  values  for  foe  ouqwt  variaUes;  also  record  foe 
expected  values  assumed  by  foe  local  variables. 

(c)  Set  Sj  to  state;  determine  foe  next  state  and  set  S£  to  it 

(d)  Determine  if  Sg  is  transioit;  if  not  mark  it  as  a  “stop  state”  and  skip  to  (3).  The  state 
is  transient  if  one  of  its  enabling  predicates  is  true  immediately  upm  reaching  foe  state.  This  means 
that  it  can  pass  on  to  another  state  immediately,  wifoout  waiting  for  fotfoer  iiqniL 

(e)  Attempt  to  make  Sg  into  a  stop  state  by  setting  “DC”  values.  That  is,  make  foe  DC 
values  sudi  foat,  upon  teadiing  state  Sg,  none  of  the  enabling  predicates  are  true.  If  successful,  go 
to  (3). 
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(0  If  5£  is  a  tnnskm  stale  and  num  than  one  tnuttitkm  lecvii^  5£  is  endiied,  ctaooae 
one  and  set  infiuts  not  yet  specified  Qf  any  exist),  so  ttui  only  me  tiansitim  leaving  5g  is  enabled; 
set  t  s  (pxi)  to  diis  tiansitim. 

3.  Ou^Mt  this  test  5/  i2, ...  /  oj,  02, ... ,  as  the  not  test  in  the  test  sequence. 

4.  Maik  the  ciause  just  tested.  If  all  ciauses  in  tiansition  I  are  now  tested,  maifc  I  as  tested. 
If  all  transitions  are  now  maiked  as  tested,  exit  to  “refining  stqn.”  Olheiwise,  continue  to  step  (5). 

5.  Set  state  to  Sf.  If  state  is  a  stt^  state  go  to  (2),  odieiwise  go  to  stq)2(b). 

Step  2(a)  assumes  diat  it  is  possible  to  set  the  input  vaiiaUes  to  values  that  make  exactly 
one  of  the  clauses  true.  If  the  protocol  is  weil  designed  diis  assumptim  will  genmally  be  tree. 
However,  there  is  always  a  possibility  this  is  not  the  case;  if  so,  the  test  designer  must  dioose  die 
values  so  that  the  clauses  will  be  tested  as  thorou^y  as  possible,  pmtuqis  in  combinadm  with  odier 
clauses.  If  a  clause  cannot  be  tested  individually,  die  questim  of  its  necessity  to  the  specificadm 
should  be  considered. 

Step  5  sets  the  staiting  state  of  the  next  test  in  the  sequence  to  die  ending  state  of  the 
cunent  test  This  makes  the  ordering  of  the  tests  follow  the  order  of  their  occurrence  in  the  actual 
protocol  executioa 

3.  Refining  Steps 

1.  Constnict  die  I/O  state  diagram  from  the  test  sequence. 

2.  Deteimine  if  die  sequence  are  unique,  so  that  from  each  state,  we  have  a  unique  input 
ouqxit  (UIO)  sequence  to  confinn.  If  not  attempt  to  extend  the.sequence  so  that  we  have  a  unique 
UIO  sequence  from  each  state. 

3.  Oieck  for  any  converging  transitions.  Maik  these,  as  potential  problems  for  testing. 

The  I/O  diagram  can  be  constructed  from  the  test  sequence  and  is  atool  to  help  the  test 

designer  insure  completeness.  This  finite  state  machine  is  often  used  as  the  staiting  point  in  test 
generation  in  the  literature. 

A  UIO  sequence  has  been  defined  as  a  sequoice  of  iiqmts  such  that,  if  the  input  sequence 
is  sqiplied  to  the  FSM  when  FSM  is  in  state  i,  die  resulting  output  sequence  could  not  have  beoi 
produced  by  the  FSM  when  the  FSM  is  in  any  other  state  [DAHB90][SIDH88].  If  die  sequence  of 
tests  aj^lied  to  a  machine  implementation  in  a  state  i  is  a  UIO  sequence,  and  the  ouqnit  is  expected, 
then  we  have  a  stronger  argument  that  the  machine  was,  in  fact,  in  state  i. 
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C.  Test  Generation  oi  the  CSMA/CD  Protocol 


In  ttiis  section,  the  test  generation  procedure  is  illustrated  through  an  mplicHion  on  a  well 
knownpiotooolfor  local  area  networks,  the  CSMA/CD  (carrier  sense  multiide  access  widi  collision 
detecdcHi)  protocol.  The  protocol  has  a  formal  qreciiication  as  a  SCM  model  in  [LUND93]. 

The  topology  of  die  CSMA/CD  is  a  simple  bos  with  a  single  charnel,  as  in  di^ayed  in  Hgure 
26.  All  stations  transmit  and  receive  on  the  dumnel.  If  mme  dian  one  station  transmits 
simultaneously,  interference  or  “collision”  occurs.  A  station  wishing  to  trarwmit  first  checks  die 
medium.  If  no  other  transmission  is  detected,  it  begins  transmitting  its  own  message.  If  a  collision 
occurs,  the  station  attempts  to  retransmit  its  message  after  waiting  a  random  time  poiod. 


Figure  26 :  Topology  of  the  CSMA/CD  Network 


The  specification  of  CSMA/CD  protocol  consists  of  the  finite  state  machine  and  the  local 
variables  of  the  network  stations  (Hgure  27)  and  the  predicate  action  table  for  the  networic  stations 
(Table  4).  The  shared  variables.  Medium  and  Signal  and  finite  state  machine  of  the  controller, 
responsible  for  die  control  of  shared  variables,  are  shown  in  Figure  28. 


Hgure  27 :  Specification  of  the  Network  Nodes 


ilie  predicate  action  table  of  Controller  is  shown  in  Table  5. 
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Figure  28 :  Orntroiltf  and  Shared  VariaUes 


The  local  variables  of  each  network  node  are  nag  and  inbiif.  Msg  is  of  die  same  type  as 
medium.  Inbvfis  used  to  receive  incoming  messages.  State  0  is  the  initial  state,  from  uiiidi  either  a 
receive  or  transmit  action  is  initiated.  States  0,2,  and  3  make  up  die  tiansmit/coUision  states,  and 
states  0  and  1  comprise  the  receiving  portion  of  the  madiine. 

The  cmtroller  continually  monitors  the  ccxnmunication  medium.  Whenever  a  nonempty 
value  is  detected  it  tiansiti«is  to  eidier  state  2  or  1,  according  to  udiether  a  collisitm  or  good 
transmissirm  occurred.  If  a  collision  occurs  Onedium  «  undefined),  die  craitroller  moves  to  state  2. 
When  all  stations  have  detected  the  collidm  (Signal(l..n)  =  collision),  die  controllor  dears  tire 
medium  and  returns  to  0.  If  a  good  transmission  occurs,  the  crnttroller  moves  to  state  1.  After 
receiving  station  accqits  die  message,  the  controller  clears  die  medium  and  returns  to  0.  The 
predicate-action  table  for  controller  is  shown  in  Table  S. 

The  network  stations  may  eidier  transmit  or  receive  fmn  the  initial  state  0.  If  a  station,  instate 
0  has  data  to  transmit,  indicated  by  a  nonempty  msg,  and  the  medium  is  dear,  it  will  transitimi  to 
state  2  and  die  message  written  to  medium.  The  variable  msg  becomes  nonempty  when  die  upper 
layer  of  the  protocol  has  data  to  send.  If  no  collision  occurred  die  OK  transition  will  set  the  state 
back  to  0.  This  is  indicated  by  the  value  of  Signcd(i),  being  set  to  dear  by  die  controller,  providing 
if  no  collisions  occurred.  If  a  collision  occurs,  dim  die  coll-D  (collision  detected)  transition  will  be 
takm.  Once  die  controller  dear  the  medium,  indicated  by  Signal(i):^  clear,  the  node  will  return  to 
stated  and  attempt  to  retransmit 

The  receive  transition  is  also  starts  frmn  state  0.  This  transition  becomes  enabled  whm  a 
message  iqipears  in  medium  with  die  station’s  address  inmediunuDA.  The  node  copies  the  message 
into  its  ii^t  buffer  inbitf,  dim  sigruils  die  corttroller  by  setting  Signal(i)  to  transceive  and  returns 
to  stated. 
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TABLE  4:  PREDICATE  ACTION  TABLE  FOR  NETWORK  NODES 


Ihnation 

Preihcate 

Action 

Xiiut 

msg  #0  A  medium  s  0 

roedhan :«  ra^ 

SigmdO)  :■  imsceive 

OK 

SignaKO  >  clear 

msg:>  0 

coU-D 

medium  ■  undefined 

SignalO)  :■  ctdliskm 

ready 

SignaKO-ckar 

receive 

mediumDA 

inbuf:"  medium; 

SignalO)  :>  lianaceive 

Generation  of  the  Protocol  test  sequence  will  be  discussed  later  in  diis  diapterakmg  with 


the  software  tool  TESTGEN. 

TABLE  5:  PREDICATE-ACTION  TABLE  FOR  THE  CONTROLLER 


‘Ihuisition 

Rredicaie 

Action 

message 

—medium  €  luiidefined,0} 

reset-M 

Signal(medium  J)A)  •  ttansceive 

medium  0; 

Signal(l..n)  :>  clew 

collision 

medium  a  undefined 

reset-C 

SignaKl- Ji) «  collusion 

mediums  0; 

Signal(l..n) :«  clew 

1.  Creating  Inputs  For  The  ^TESTGEN*’  Program 

The  software  tool  that  automates  the  generation  of  test  sequences  is  called  ‘TESTGEN.” 
The  general  structure  of  TESTGEN  is  shown  in  Rgure  29.  The  iiqwts  of  the  program  are  two  text 
files  which  are  created  and  named  by  die  user. 


FSM  (Text  File) 

V' — 

Generated  Test  Sequence 

\  TESTGEN  )  ^ 

Predicate-Action  Table 
(TextFQe) 

frextFOe) 

Figure  29 :  The  General  Structure  of  TESTGEN  Program 
The  irqnit  files  are  easily  created  utilizing  die  following  procedures.  Before  creating  the 
FSM  irqnit  file,  the  user  should  assign  a  number  to  eadi  transition  of  die  FSM .  This  distinguishes 
each  arc,  even  thougli  they  may  r^tesent  the  same  transititHi  name.  The  numbered  FSM  of  die 
CSMA/CD  protocol  is  shown  in  Figure  30. 
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(4) 


Hguie  30 :  Assignment  of  Numbers  to  Transitions  of  CSMA/CD  Protocoi 

To  create  ttie  first  file,  the  user  first  r^redfies  the  initial  state  of  the  FSM  as  the  first  line 
in  the  FSM  iniwt  file.  Each  line,  thereafter,  rqaesents  a  transition  arc  and  is  entered  in  the  format 
From  State  To  State  NunUter  Assigned  Transition  Name 

widi  a  single  space  bdween  eadi  fidd. 

It  is  a  practical  way  to  enter  transitirm  arcs  starting  fnnn  initial  state,  listing  all  ou^oing 
arcs  and  tiien  continuing  with  the  next  state,  ‘nansiticm  arcs  can  be  entered  in  any  order  as  Icmg  as 
they  have  the  previous  structure. 

An  example  FSM  ir^nit  file  for  the  CSMA/CD  protocol  is  shown  in  Hgure  31.  The  “0** 
in  the  first  line  shows  the  initial  state  of  our  example  CSMA/CD  protocol. 

0 

oil  r«c«lv« 

023  xaic 
032  coll-D 
10  4  raadir 
2  0  4  ok 
235  coll-D 
307  roadr 

Hgute  31 :  FSM  b^rutHle  of  CSMA/CD  Protocol 
Figure  32  shows  the  parts  of  a  transition  arc  and  tiieir  meanings  in  FSM  input  file. 

Oil  receive  - ►  Transition  Name 

From  State  To  State  Transiticx)  Number 

Figure  32  '.Representation  of 'Dansitirm  Arcs  in  FSM  Input  Rle. 
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TtmaBCOodiBputfaecaat^predlcateactionkMe(PAT)cilltK6tpedBedpa^oe^ 
file  is  ciealBd  in  the  same  tabular  fioimat  as  the  pretficttieHicitoii  toAfe.  Each  colaain  of  die  PAT  is 
sqMnted  witti  vertical  bar  *  r  with  a  qnoe  on  each  side,  so  that  it  is  disdngaidiabie  from  the  odw 
hdde  entrees.  The  *  r  delineates  die  boidera  of  traMiti<Mi,;aedicate  and  actioocohiiiuis  of  die  f  AT. 
Muldide  action  statement  should  be  sqianted  with  a  semi-colon  (;).  If  no  action  is  to  be  taken 
a  transition,  the  keyword  '‘no"  most  be  entered  as  die  action  part  of  the  ii^  file.  If  a  transition 
occurs  evoy  time  we  enter  a  state,  it  is  indicated  by  putting  keyword  die  “true"  in  die  predicate  part 
of  die  input  file.  An  example  of  predicate-action  input  for  the  CSMA/CD  {Hotocol  is  tiiown  in 
Hgure33. 

x>lt  I  Mg  /■  «Bpcy  and  Mdlu*  •  aag>ty  I  Mdlua  t>  sag  i  aignaKi)  tranaealva  I 

ok  I  atgnald)  -  claar  I  aag  ,•  aapCy  I 

coll-D  I  aMdluai  >  unldaotif  I  aignal<l)  <•  colllaloo  I 

raa^y  I  algnal(l)  •  claar  I  no  I 

racaiva  I  aadlua  ■  (x.x.l)  I  inbuf  >•  aadlua  i  algnal(t)  tranaealva  I 

Hgure  33 :  Predicate-Action  Hie  Input  of  CSMA/CD  Protocol 
An  example  line  in  the  predicate-action  ir^iut  file  is  shown  in  Figure  34. 

mil  I  t  madinai :> miC  t^nilG) :* tnoMciva  I 

/“t  W  M  1  *  I  * 

Tianaitiao  Tiantkiaa  Fint  Ritoiowal  Seomid  dedicate  Hnt  SepMaiinw  Seoaod  Aktkai 

Name  Boadar  Piedicate  Symbol  Pndicale  Bolder  Actioa  Symbol  AdioB  Bolder 

Hgure  34  £xample  b^t  line  of  Predicate- Action  Hie 
Since  the  predicate  action  ii^iot  is  a  text  file,  some  relational  symbols  are  not  readily 
apparent  They  need  to  be  represented  in  a  format  that  can  be  easily  odeted  fiom  the  keyboard  yet 
understandable  by  die  program.  The  method  used  in  this  thesis  to  handle  this  problem  is  diown  in 
Hgure  35. 

If  diere  is  more  than  one  clause  in  a  disjunctive  predicate  part  of  a  transition  it  is  difScult 
to  determine  which  predicates  need  to  be  enabled  to  make  a  transition  occur.  The  TESTGEN 
program  is  capable  of  parsing  and  presenting  clauses  in  following  form 

•  first  clause  relational  symbol  second  clause 

•  first  clause  relational  symbol  (second  clause  relational  symbol  third  clause) 

•  (first  clause  relational  symbol  second  clause)  relational  symbol  third  clause 

The  TESTGEN  program  represent  these  relational  clauses  by  puttir^  the  relational 
symbol  between  two  clauses  togedier  with  the  values  of  the  ir^t  variable  to  the  ou^mt  taUe.  The 
relational  symbol  between  the  relationai  clauses  in  parendiesis  is  put  in  the  output  file  in  parendiesis 
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Rdatkmal  Text 
Symbols  Symboto 

X #y  -^xMy 

0-^  empty 

X  Ay  -4x  andy 

X  vy  -»x  ory 

'Assignmentto  available 

X  ©  y  X  mod-t-  y 

Rgure  35  :  Relational  Symbols  and  Their  Represoitatimis 

so  it  is  rfisrtngiiishahte  from  Other  relational  symbol.  If  the  enaUing  predicate  has  more  than  three 
clauses  the  TESTGEN  program  may  not  cotrectly  rqnesent  diese  clauses  in  the  ou^t  test 
sequence.  The  user  should  ccmtrol  die  ouqmt  test  sequence  for  diese  transidtxis. 

If  iiqmt  variables  are  record  stroctures  such  as  medium,  msg,  inbut,  assignment  or 
cmnpaiiscm  of  a  specific  fields  of  the  record  are  dcme  widiin  parentheses  and  by  putting  ‘*x'*  inthe 
positions  diat  is  unimportant  For  example,  assume  a  variable  “Z”  is  a  record  stiucture  widi  three 
subparts  a,  b  and  c.  Assignment  of  the  value  “3”  to  the  ‘a’  field  of  Z  should  be  in  the  format  - 
(3,x,x)."  This  means  3  is  assigned  to  *a’  and  no  changes  are  made  to  ‘b’  and  ‘c.’  The  TESTGEN 
program  finds  local  and  shared  variatde  by  parsing  (dedicate  action  input  file  so  instead  of  entering 
different  rqnesentations  of  one  variable  such  as  mediumJ^A  or  mediumSA,  entering  variables  in 
this  format  helps  program  determine  the  variable  structure  and  makes  ou^t  file  easy  to  read. 

Comparisons  and  assignments  to  arrays  should  be  entered  in  the  format  Af/j=va/ue.  This 
may  create  more  duui  one  representation  of  the  same  variable  in  the  output  file  but  it  makes  the 
oufout  test  sequoice  more  understandable. 

2.  Procedure  Of  The  Protocol  Test  Sequence  Generator 

The  algorithm  of  the  test  generator  consists  of  two  major  subparts:  the  first  part  finds  all 
possible  paths  and  cycles  in  tiie  FSM  starting  fiom  the  initial  state.  It  prints  the  list  of  paths  and 
cycles  to  a  text  oufout  file,  named  by  the  user.  It  also  ensures  ttiat  tiiere  is  a  path  fiom  all  cycles 
eventually  returning  to  the  start  state.  If  it  can’t  find  such  a  path  it  will  print  out  a  message,  warning 
the  user  of  possible  errors  in  the  specification  of  the  protocol. The  pseudo-code  algorithm  for  finding 
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all  paths  and  cycles  of  FSM  is  illiistrated  In  Hgiue  36.  Finding  all  possttde  tmshkm  sequences 
ensues  that  eadi  instance  of  each  tiaasiticm  is  tested. 


Parse  the  FSM  Input file  aid  make  a  Ust  of  transition  aresfUstjiiftrtaisitUms): 

Take  one  are  originaingfnm  the  initial  stae  put  it  into  a  listjyjHtths; 

If  there  is  more  than  one  are  ” 

^^ed  other  ares  to  the  end  of  Ustjfjfoths 

Start  with  the  first  ae  in  the  listjfjHtths  and  find  the  destinatUm  node 

Maimtoop: 

loop  until  there  is  no  pah  proeessed  in  the  list  of  Jpahs 
LoOt for  other  mes  ori^nadngfrom  the  de^nadon  node  in  the  listjfjransition 
ff  there  is  one: 

Cheek  dutt  are  is  pa  in  the  path  generated 
if  it  is 

Mak  the  pah  as  cyele  found 

Mark  the  pah  generated  as  proeessed  and  ddp  the  next  path  in  the  list_of_paths 
replace  the  starting  ac  with  the  arc  a  the  end  of  the  pah  on  the  next  unprocessed  path 
go  to  the  main  loop 

else 


Append  that  arc  to  the  aigitud  arc 
endtf: 

elsif  there  is  more  than  one  arc 

Copy  the  pah  generaed  and  append  the  copy  to  the  end  of  listjof  pahs  along 
with  the  aher  arc  or  arcs  originaing  from  destination  node  appeiuled 

else 

“There  may  be  an  error  in  the  protocol.  Ittform  the  user.” 
end  if; 

check  to  see  destination  node  is  initUil  state 
if  it  is  then 

mark  the  path  generaed  as  a  new  path  and  skip  to  the  next  path  in  the  listjfjtaths 
replace  the  starting  arc  with  the  ac  at  the  end  of  the  path  on  the  next  unprocessed  pah 
else 

replace  the  starting  ac  with  the  ac  originatingfrom  the  destinaion  node 

end  if; 
end  loop: 


Hgure  36 :  Algorithm  forHnding  Paflis  and  Cycles  in  the  FSM 


To  trace  all  the  possible  paths  which  could  be  generated,  a  queue  of  linked  lists  is 
implemoited.  Hie  trace  is  as  follows:  Starting  with  the  initial  state,  all  transitions  are  placed  into 
the  queue.  The  first  entry  is  dequeued,  becoming  tiie  current  oitry,  and  is  used  to  continue  the  trace. 
The  current  oitry  remains  so  until  it  describes  a  cycle  back  to  the  initial  state. 

All  transitioiis  out  of  the  last  node  of  tiw  current  patii  are  determined,  and  one  of  them  is 
sqipended  to  the  current  oitry. 

Any  other  transitions  are  each  appended  to  a  copy  of  the  current  path  and  placed  at  the 
Old  of  the  queue  (list.of  .paths).  When  the  initial  state  is  reached,  next  patii  in  the  queue  becomes 
current  patii.  This  procedure  continues  until  the  queue  is  empty. 

The  program  starts  with  an  arc  originating  from  tiie  initial  state.  In  our  example  CSMA/ 
CD  protocol  tiie  first  arc  selected  is  transition  #1  (0 1 1  receive).  It  is  inserted  to  the  list_of_paths. 
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Since  there  is  more  than  one  transition  leaving  the  initiai  state,  the  otter  (02  3  transmit),  (032  coU- 
D)  arcs  are  also  inserted  to  the  list_of_paths.  Then  desdnatitHi  node  “1”  of  transition  #1  is  found 
from  the  list_of_transiti(xi  and  since  there  is  one  transition  (transititm  #4)  leaving  destinati>  m  node; 
it  is  appended  to  the  end  of  our  path.  Then  transition  #4  becomes  current  arc.  Since  the  destination 
node  of  the  transition  #4  is  0  (initial  state)  the  path  is  marked  as  processed.  The  current  entry 
becomes  tte  last  arc  in  the  next  unprocessed  transition  sequence  (transition  #3).  The  procedure 
continues  until  all  paths  and  cycles  originating  from  the  initial  state  are  found.  The  steps  of  finding 
paths  and  final  path  list  at  the  end  of  procedure  FIND_PATHS  for  CSMA/CD  protocol  is  shown  in 
Figure  37. 


Hguie  37 :  The  List  of  Paths  Generated  witt  TESTGEN  for  CSMA/CD  Protocol  FSM 


3.  Preliminaries 

hi  our  example  many  of  our  variables  perform  as  both  input  and  output  sources.  The 
shared  variables  medium.  Signal  and  local  variable  msg  are  input  and  ouqmt  variables.  The  second 
part  of  the  TESTGEN  determines  our  input  and  output  variables.  If  a  variable  is  used  as  both  an 
input  and  output  variable  it  is  marked  by  placing  (i)  or  (o)  next  to  them  to  indicate  its  current 
usage.The  program  reads  the  transitions,  predicates  and  actions  associated  with  each  transition  horn 
the  predicate  action  table  (PAT).  It  tten  creates  tte  test  sequence  table  and  lists  all  transition 
sequences  starting  from  tte  initial  state  by  using  listjaf  jpaths.  It  prints  each  transition  witt  tte 
expected  values  of  any  local  and  shared  variables.  It  also  prints  the  action  to  be  taken  if  the  predicate 
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associated  widi  transition  is  enabted.  Pseudo-code  of  the  second  part  of  TESTCSBN  is  shown  in 
Figure  38. 


Parse  the  predicate  action  input  file 

Determine  transitions,  local  and  shared  variables  predicates  and  actions  associated  with  each 
tratuddon 

Determine  and  mark  the  expected  values  for  the  output  variables  and  record  the  expected  values 
assumed  by  local  variables  for  each  tranktion 
Print  the  input ,  output,  and  shared  variables 
Take  the  first  path  from  the  list  of j>aths 
loop  until  no  more  list  remained  in  the  list  of  files 
begin  with  the  first  transition  in  the  patiT 
set  Si  to  the  originating  node  of  the  transition 

set  input  variables  of  this  transition  according  to  the  predicate  action  table 
^  input  variable  is  a  record  type 
set  mimportant  fields  with  V* 

end  if  ; 

set  other  input  variables  "DC"  for  don’t  care 
set  output  variables 

set  Se  to  the  terminal  state  of  current  transition 
Print  the  completed  test  to  the  output  file 
set  Si  to  the  Se 
^  not  end  cf  path 

replace  the  current  transition  with  the  next  transition  in  the  path 

else 

mark  the  path  as  processed 

replace  the  current  transition  with  the  first  transition  of  the  next  unprocessed  path 

end  if: 
end  loop 

Figure  38 :  Pseudo-Code  Algorithm  for  Generating  Protocol  Test  Sequence 


4.  Test  Sequence  Generation 

The  TESTGEN  program  begins  with  the  first  transition  (#/  receive)  in  the  path  list 
generated  by  the  FIND_PATHS  procedure.  According  to  the  predicate  action  input  file  to  enable 
this  transition,  the  DA  field  of  medium  must  be  set  to  the  station’s  address,  which  we  assume  to  be 
i.  The  remaining  fields  of  the  record  medium  may  be  any  values,  and  are  indicated  by  ‘x’  in  the 
ouqxit  table  (Hgure  39).  The  other  input  variables  are  set  to  ’’don’t  car^'  ox  DC. 

When  the  receive  transition  occurs,  signal(i)  should  be  set  to  transceive,  and  inbitf  should 
contain  me  value  which  was  previously  in  medium.  S;  is  set  to  source  state  of  the  current  transition 
(in  this  case  0),  and  Se  to  the  to  terminal  state  (in  this  case  1).  This  completes  the  first  test  in  the 
sequence  and  these  values  are  ouqmtThe  clause  and  transition  are  now  maiked  “tested”.  The  value 
of  Sj  is  now  set  to  1,  and  next  transition  in  the  path  is  called. 

The  next  iteration  is  the  ready  transition  from  state  1.  The  values  selected  are  the  second 
test  in  the  output  table  (Bgure  39).  The  ending  state  of  this  test  is  state  0  the  initial  state,  so  the  path 
is  maiked  as  processed. 
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At  the  next  iteration  first  transition  in  the  next  luqxocessed  (Mth  (xm//)  is  diosen, 
foliowed  by  file  OK  transitim  back  to  state  0.  The  same  process  continues  with  transiticm  coU-D, 
which  takes  the  machine  state  3,  and  the  ready  transition  tMums  it  to  state  0.  That  the  Xmit 
transition  is  chosen  a  second  time  in  the  iast  path  v^di  takes  the  machine  state  2;  then  transition 
coU-D  is  diosen  whidi  is  dififerent  from  {nevious  sequence;  fiiat  takes  die  madiine  to  state  3  and 
ready  transidon  again  returns  it  to  the  initial  state.  At  this  point  all  possible  transitkm  sequoices 
have  been  processed. 

The  table  generated  by  the  TESTGEN  program  for  the  CSMA/Q>  protocol  is  shown  in 
Hguie  39.  The  table  lists  all  nine  possible  transidons  according  to  their  order  of  occurmice.  It  is 
reladvely  easy  to  test  all  sequences  of  a  transitions  by  simply  following  the  order  in  the  table. 


Trana 

1 

1 

input  varlablaa 

l**l 

output 

varlablaa 

1 

ISllaMdium(l) iBag(l)  Islgnal(i) 

I**! 

Inbuf 

ImadluB(o) iBag(o) laignal (o)  ISal 

racalva 1 0 

Kl.X.X)  IDC  IOC 

I**! 

aadluBl — 

1 

Itranacalval 

11 

raady 

11 

IOC 

IDC  Iclaar 

•  ••I 

— 

1  -- 

I 

1—  1 

01 

XAit 

10 

laaipty 

1 /■anptylOC 

I**! 

— 

iBog 

1  ** 

Itranacalval 

31 

ok 

13 

IOC 

IDC  Iclaar 

I*»l 

— • 

1  *** 

laapty 

1—  1 

01 

coll-O 

10 

lundafinadlOC  IOC 

I**! 

Icolllalon  1 

31 

raady 

13 

IOC 

IOC  iclaar 

I**! 

1—  1 

01 

xaic 

10 

lanpty 

1 /aamptylOC 

l**l 

— 

Inog 

1 

1 tranacalva I 

31 

coll-D 

13 

lundafinadlOC  IOC 

I**! 

•• 

Icolllalon  1 

31 

raady 

13 

IDC 

IOC  Iclaar 

[••I 

— 

I  — 

!-• 

1—  1 

01 

Hgure  39 :  The  Test  Sequence  Table  Generated  with  TESTGEN  for  CSMA/CD  protocol 

5.  Refinement 

The  first  refining  step  calls  for  the  construction  of  die  I/O  diagram.  This  diagram  can  be 
constructed  from  the  sequence  of  tests  generated.  In  diis  case,  because  there  are  no  transient  states, 
there  are  four  states  which  correspond  to  the  four  states  of  the  spedfication;  and  the  arcs  between 
states  are  the  same  set  as  in  die  spedfication.  The  only  difference  is  in  the  labeling  of  the  arcs;  for 
the  I/O  diagram,  the  label  on  each  arc  is  the  set  of  values  if  die  input  and  ouqiut  variables,  as  shown 
in  output  table  IHgure  39. 

Next  we  must  determine  if  the  sequence  is  a  UIO  sequence.  Consider  the  first  test  in  the 
table,  the  receive  transition.  If  the  machine  is  in  state  0  and  we  tqjply  die  inputs  for  the  first  test,  the 
outputs  are  the  transceive  value  in  Signal(i)  and  a  copy  of  medium  in  inbuf.  The  user  may  confirm 
that  in  no  other  state  does  this  combination  occur;  so  for  the  first  state  and  test,  we  have  an  UIO 
sequoice.  From  state  1,  the  ready  transition  is  considered.  This  transition  leads  back  to  state  0;  note 
that  another  ready  transition  leads  from  state  3  to  state  0.  This  means  that  there  is  not  a  UIO 
sequence  for  states  1  and  3.  This  makes  it  difficalt  for  the  test  designer  to  confirm  these  states.  Thme 
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is  how^w  a  ino  sequence  leading  into  ttiese  states:  so  the  lade  of  a  UIO  aeqiienoe  fiom  tbese  itMBS 
is  less  distuiiring. 

Finally  a  chedt  for  omveiging  transitions  diows  diat  there  is  one  case  of  diis:  the  raidy 
transition,  leading  to  state  0  from  tx)di  states  land3.Thetestdesipia'iniistbeawareofd)is,asa 
possible  source  of  proUems  in  the  execution  of  tests. 
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V.  AFPUCATIONS  OF  THE  SUPERTRACE  AND  TEST6EN  PROGRAMS 


In  diis  dupter  Simple  Mushiomn  with  Supertiace  and  Big  hAiduoom  witti  Siqper  race  are 
demonstrated  with  sevmal  examines.  Bmh  i»ograms  are  nm  with  diffoent  protocols  to  give  a 
specific  view  of  the  Supettrace  algorithm. 

In  the  first  section.  Simple  Mushroom  widi  Si4)eitrace  will  be  used  to  analyze  a  shiqtle 
example  four  machine  protocol  >riiich  illudrates  some  basic  a^)ects  such  as  detecting  unspedfied 
receptions,  unexecuted  transitions  etc.  Then  information  transfer  jduse  of  a  full  duplex  LAP-B 
protocol  specified  by  the  CFSM  model  will  be  analyzed.  Latnr,  the  Big  Mushroom  wifo  Supettrace 
will  be  used  to  aiudyze  the  Go  Back  N  protocol  with  different  window  sizes  and  die  Token  Bus 
protocol,  which  illustrates  important  aqiects  of  Supettrace  algorithm. 

In  the  second  part  of  this  chapter,  an  application  of  the  protocol  test  sequence  generator 
program  (TESTGEN)  to  the  well  known  FDDI  protocol  is  illustrated. 

A.  Applications  Of  Mushroom  Program  With  Supertrace 

1.  CFSM  Model  with  Supertrace 
a.  Simple  Four  Machine  Protocol 

The  specification  of  the  protocol  using  the  CFSM  model  is  shown  in  Figure  40.  This 
sample  is  chosen  to  demonstrate  the  coverage  of  supertrace  algorithm  with  protocols  that  has 
relatively  small  number  of  states.  Each  machine  sends/receives  a  message/acknowledgment  from 
other  machine.  Machines  2  and  3  also  have  another  send  transition  fimn  state  1  to  state  3.  The  FSM 
description  of  the  protocol  is  shown  in  Hgure  41  and  analysis  results  obtained  by  the  simple 
Mushroom  widi  supettrace  is  shown  in  Figure  42.  The  anal3rsis  generated  36  global  states.  There 
are  three  unspedfied  receptions  and  one  unexecuted  transitiotL  No  deadlodcs  or  channel  overflows 
are  recorded.  The  fnaximnin  channel  size  2.  These  results  ate  obtained  by  simply  entering  the  FSM 
text  file  as  an  input  to  the  program.  This  analysis  would  be  difficult  to  do  manually,  even  for  a 
simple  spedfication  like  this  one. 

The  analysis  results  obtained  is  the  same  with  simple  mushroom  [BULB93]  results, 
showing  the  coverage  and  reliability  of  Supettrace  for  small  protocols  is  around  100%. 
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Machine  1  Machine! 


Hgure  40 :  Specification  of  the  example  fourmadiine  protocol 


start 

nufflber.ofjmachlnas  4 

machlna  1 

state  1 

trans  -D  2  2 

state  2 

trans  4^A  1  3 

machine  2 

state  1 

trans  -D  3  3 

trans  +D  2  1 

state  2 

trans  -•'O  1  4 

machine  3 

state  1 

trans  -A  3  1 

trans  >022 

state  2 

trans  -014 

machine  4 

state  1 

trans  >023 

state  2 

trans  -012 

Inltlal.state  1111 

finish 


Hguie  41 ;  FSM  text  file  for  the  example  protocol 


SI 


RUCHABILirr  JtHALYSIS  o(  i  Caur_pMchliM.(aa 
SPSCirZCATIOM 


Machin*  1  stata  Tranaltlona 


Prom  I  To  I  ochar  machlna  I  Tranaition 


112  1  2  I  a  D 

2  111  3  I  r  A 


Machlna  2  scata  Tranaltlona 


From  I  TO  I  othar  machlna  I  Transition 


113  1  3  Iso 

112  1  1  I  r  D 

2  111  4  I  r  D 


Machlna  3  Stata  Transitions 


From  I  TO  I  othar  machlna  I  Transition 


113  1  1  ISA 

112  1  2  I  r  D 

2  111  4  ISO 


Machlna  4  Stata  Transitions 


From  I  To  I  ochar  machlna  I  Transition 


112  1  3  I  r  D 

2  111  2  Iso 


RBkaUBILlTr  QRAPH 


1  (  l.B.B.B,  1,B.B.B,  l.B.B.Bl 

•D  2  (  3.D  ,B.B.  l.B.B.B,  l.B.B.B.  l.B.B.B]  3 

-0  3  (  1,B.B,B,  3,B,D  ,E.  l.B.B.B,  l.B.B.B]  3 

-A  1  t  l.B.B,B.  l.B.B.B,  3, A  .B.B.  l.B.B.B]  4 

3  t  3,0  ,B,B,  l.B.B,B.  l.B.B.B.  l.B.B.B] 

-0  3  C  3.0  .B.B.  3,B.O  ,B,  l.B.B,B,  l.B.B.B]  5 

>0  1  (  3,B,B,B.  3.B.E,B,  l.B.B.B.  1.B.B.B]  6 

-A  1  (  3.0  .B.B.  l.B.B.B.  3. A  .B.B.  l.B.B.B]  7 

3  (  l.B.B.B,  3,B.O  ,B,  l.B.B.B.  l.B.B.B] 

-0  3  (  3.0  ,B.B,  3,B.O  .B,  l.B.E,B,  l.B.B.B]  0 

•A  1  C  l.B.B.B,  3.B,0  ,B.  3.A  .B.B.  1,B.B,B]  8 

«0  3  (  l.B.B.B,  3,B.B.B.  3.B,B,B.  l.B.B.B]  9 

4  (  l.B.B.B.  l.B.B.B,  3.A  .B.B.  l.B.B.B] 

-0  3  (  3,0  ,B,B,  l.B.B.B.  3. A  .B.B.  l.B.B.B]  0 

-0  3  (  l.B.B.B.  3,B.O  ,E,  3,A  .B.B.  l.B.B.B]  0 

5  [  3,0  .B.B.  3,B,0  ,B,  l.B.B.B.  l.B.B.B] 

-A  1  C  3.0  .B.B.  3,B,0  .B.  3. A  .B.B,  l.B.B.B]  10 

♦0  3  (  3,0  .B.B.  l.B.B.B.  3.B,B,E,  l.B.B.B]  11 

6  t  3.B,B,B,  3,B.B,B,  l.B.B.B.  l.B.B.B] 

-A  1  [  3,B,B,B.  3,B.E.B.  3. A  .B.B.  l.B.B.B]  13 

7  [  3,0  ,E,B,  l.B.B.B,  3. A  .B.B,  l.B.B.B] 

^A  3  (  1,0  .B.B,  l.B.B.B,  3,B,B,B,  l.B.B.B]  13 

•0  3  [  3.0  ,E,B,  3,B,0  ,B,  3, A  .B.B.  l.B.B.B]  0 

♦0  1  (  S.B.B.B,  3,B,B,B,  3, A  .B.B.  l.B.B.B]  0 

8  [  l.B.B.B,  3,B.O  ,B.  3, A  .B.B,  l.B.B.B] 

-0  3  (  3.0  ,B.B,  3,B,0  ,B,  3, A  ,B,B,  l.B.B.B]  0 

9  I  l.B.B.B,  3,E,B,B,  2,E,B,B,  l.B.B.B] 

-0  3  (  3.0  ,B.B,  l.B.B.B.  3,E,E,B.  l.B.B.B]  0 

-0  4  C  l.B.B.B.  l.B.B.B,  l.E.B.O  ,  l.B.B.B]  14 

10  [  3,0  ,B,B,  l.E.O  ,E.  3, A  ,E,E,  l.B.B.B] 

*k  3  (  1,0  .B.B.  l.E.O  .B,  l.B.B.B.  l.B.B.B]  15 

11  (  3,0  ,B,B,  3,B,B,B,  3,B,B,B,  l.B.B.B] 

-O  4  t  3.0  ,B,B,  3,5,8.E.  l.E.B.O  ,  l.B.B.B]  16 

13  (  3,B,B,B,  3,E,B.B,  3,A  ...B,  l.B.B.B] 

*k  3  [  l.B.B.B,  3,B,E,E,  l.B.B.B,  l.B.B.B]  17 

13  (  1,0  ,E,B,  l.B.B.B,  l.B.B.B,  l.B.B.B] 

-0  3  [  3.0  0  ,B,B,  l.B.B.B,  3,B.B.B.  l.B.B.B]  18 

-0  3  [  1,0  ,B,B,  3,B,0  ,E,  l.B.B.B,  l.B.B.B]  0 

>0  1  (  l.B.B.B,  3,B,B,E.  l.B.B.B,  l.B.B.B]  0 

14  [  l.B.B.B,  l.B.B.B,  l.E.B.O  ,  l.B.B.B] 

-0  3  [  3,0  ,B,B,  3,B,B,B,  l.E.B.O  ,  l.B.B.B]  0 

-A  1  [  l.B.B.B,  l.B.B.B.  3. A  ,B,0  ,  l.B.B.B]  19 
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*0  3  (  1,K.K.I.  3.I.I.I.  1. 1.1.1.  2.B.I.I)  20 

15  [  1.0  .B.B.  3.B.D  .1.  3.I.I.I.  1.B.I.B] 

•0  2  t  2.0  D  .a.B.  3.1.0  .B.  3.B.B.B.  1.B.B.B]  21 

16  t  2.0  .B.B.  3.B,B.B.  l.B.B.O  .  1.B.B.B] 

•A  1  I  2.0  .B.B.  3.B.B.B.  3. A  .B.O  .  l.B.B.BI  22 

*0  3  (  2.0  .B.B.  3.B.B.B.  l.B.B.B.  2.B.B.BI  23 

17  [  l.B.B,B.  2.B.B,B.  3.B.B.B.  1.B.B.B] 

-0  2  (  2.0  .B.B.  2.B.B.B.  3.B.B.B.  l.B.B.B]  24 

10  I  2.0  0  .B.B.  l.B.B.B.  l.B.B.B.  l.B.B.B] 

•0  3  (  2.0  0  .B.B.  3.B.0  .B.  l.B.B.B.  l.B.B.B]  0 

«0  1  [  2.0  .B.B.  2.B.B.B.  l.B.B.B.  l.B.B.B]  0 

19  (  l.B.B.B.  3.B,B.B.  3. A  .B.O  .  l.B.B.B) 

-0  2  [  2.0  .B.B.  l.B.B.B.  3. A  .B.O  .  l.B.B.B]  0 

*0  3  [  I.B.B.B.  l.B.B.B.  3. A  .B.B.  2.B.B.B]  2S 

20  (  l.B.B.B.  3,B,B.B.  l.B.B.B.  l.B.B.B] 

-0  2  (  2.0  .B.B.  l.B.B.B.  l.B.B.B.  2.B.B.B]  0 

-A  1  [  I.B.B.B.  l.B.B.B.  3. A  .B.B.  2.B.B.B)  0 

-0  2  t  I.B.B.B.  l.B.B.B.  l.B.B.B.  l.B.O  .B]  26  _ 

21  t  2.0  0  .B.B.  l.B.O  .B.  l.B.B.B.  1.B.B.B]*** . •UoapWif l«d  MCApClon' 

22  (  2.0  .B.B.  l.B.B.B.  3. A  .B.O  .  l.B.B.B] 

*A  3  (  1.0  .B.B.  l.B.B.B.  l.B.B.O  .  l.B.B.B)  27 

*0  3  I  2.0  .B.B.  l.B.B.B.  3. A  .B.B.  l.B.B.B]  20 

23  (  2.0  .B.B.  l.B.B.B.  l.B.B.B.  l.B.B.B] 

-A  1  (  2.0  .B.B.  l.B.B.B.  3. A  .B.B.  2.B.B.B]  0 

-0  2  t  2.0  .B.B.  l.B.B.B.  l.B.B.B.  l.B.O  .B]  29 

24  (  2.0  .B.B.  l.B.B.B.  3.B.B.B.  l.B. B.B] l«d  AACAptioo***** 

25  (  l.B.B.B.  l.B.B.B.  3. A  .B.B.  2.B.B.B] 

-D  2  [  2.0  .B.B.  l.B.B.B.  3. A  .B.B.  l.B.B.B]  0 

-D  2  [  l.B.B.B.  l.B.B.B.  3. A  .B.B.  l.B.O  .B]  30 

26  (  l.B.B.B.  l.B.B.B.  l.B.B.B.  l.B.O  .B] 


-0 

2 

( 

2.0  ,E.B,  l.B.B.B, 
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2,0  0  .B.B.  3, B.B. 

,E.  l.B.B.O  .  l.B.B.B] 

31 

>0 
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1.0  .B.B,  l.B.B.B, 

3,8.B,B.  2,B,B.B]  32 
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2,0 
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l.B.B.B,  3. A  .B.B. 

2,S.B,B] 

*A 

3 

( 

1.0  ,B,B,  l.B.B.B. 

l.B.B.B.  l.B.B.B]  0 

-0 

2 
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2,0  ,B,B,  l.B.B.B. 

l.A  .B.B,  1,B,0  ,B] 

33 

29 
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2.0 

.B, 

B, 

l.B.B.B,  l.B.B.B,  1. 

,E.D  ,B] 

-A 

1 
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2,0  ,E,B,  l.B.B.B, 

l.A  ,E,E.  l.B.O  .B] 

0 

30  (  l.B.B.B.  l.B.B.B.  3, A  .B.B.  l.B.O  ,B] 

-0  2  t  2.0  ,B.B.  l.B.B.B,  3. A  .B.B.  l.B.O  ,B]  0 

31  (  2,0  0  ,B.B,  l.B.B.B,  l.B.B.O  ,  l.B.B.B] 

«0  3  (  2.0  0  .B.B.  3,B,B.B,  l.B.B.B.  2.B.B.B]  34 

32  I  1,0  .B.B,  l.B.B.B.  l.B.B.B,  l.B.B.B) 

-0  2  (  2,0  D  .B.B.  3,B.E.B.  l.B.B.B.  l.B.B.B)  0 


-0 
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1 

1.0  .B.B.  l.B.B.B. 

l.B.B.B.  l.B.O 

.B] 

IS 

13  (  2,0 

.B.B. 

l.B.B.B,  l.A  .B.B. 

l.B.O  .E] 

*A 

3 
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1,0  .B.B,  l.B.B.B, 

3,8.B.B.  l.B.O 

.E] 

0 

34  (  2.0  0  ,B,B,  l.B.B.B.  l.B.B.B,  2,E,B,B] 

•0  2  (  2,0  0  ,B,B,  l.B.B.B.  l.B.B.B,  l.B.O  ,B]  36 

IS  (  1,0  ,E.B,  l.B.B.B,  l.B.B.B,  l.B.O  ,B] 

-0  2  (  2,0  0  ,B,B,  l.B.B.B,  l.B.B.B.  l.B.O  ,B1  0 

36  I  2,0  0  ,B,B,  l.B.B.B,  l.B.B.B.  l.B.O  .B]*****»«»**Un*p«cifl*d  RacapCloD' 

SUMMARY  OF  REACHABILITY  ANALYSIS  (ANALYSIS  COMPLETED) 


Total  nuabar  of  stataa  g«n«rat«d  i  36 
Nuaibar  of  atataa  aoalyzad  ■  16 
nuabar  of  daadlocka  <  0 
nuabar  of  unapaciflad  racaptlaoa  i  3 
aaxlauB  aaaaaga  quaua  alza  ■  2 

channal  ovarflow  iHONB 


UNEXECUTED  TRANSITIONS 


1 

Machine 

2  Unexecuted  Transitions  1 

1  From 

1  To  1 

other  machine  1  unexecuted  Transition  1 

1  2 

1  1  1 

4  1  r  D  1 

Hgure42  :  Program  Output  for  ttie  Example 
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ft.  AMofysisOflitfimnatiomTraM^trPluattOfTluIx^BFrotoeoi 


In  this  SectkMi.  analysis  of  a  Data  Link  ConHoi  (I%jC)  prottxxd  is  described  using 
die  Simple  Mushroom  widi  Supeitrace  inogram.  The  physical  layer  of  IXX:  (LAP-B)  protocol  was 
modeled  and  analyzed  with  CFSM  model  [LUND86]. 

The  analysis  of  known  protocols  is  important  because  it  help  us  to  detomine  the 
correctness  and  the  coverage  of  die  Supertrace  alg<Hithm.  It  is  also  an  excellent  example  of  how  the 
total  number  of  global  states  can  grow  very  large,  even  for  such  a  limited  protocol. 

This  analysis  demcuistrates  the  main  feature  of  the  Siqiertrace  algorithm,  improved 
coverage,  where  there  is  insufficient  memoiy  available  to  conduct  a  fell  state  analysis.  The 
description  of  the  information  transfer  phase  is  explained  below  as  it  ^ipeais  in  [LUND86]. 

The  network  nodes,  uhidi  communicates  by  die  {uotocol,  omsist  of  Data  Terminal 
Equipment  (DTE)  and  a  Data  Qrcuit  Terminating  Equipment  (DCE).  hi  this  model,  DTE  and  DCE 
are  considered  process  1  and  process  2  reflectively.  Each  of  diese  processes  are  also  modeled  as 
three  sub-iuocesses:  Sender.  Receiver  and  Frame  Assembler  Disassembler  (FAD). 

Figure  43  shows  die  (uocesses  and  their  interrelationship.  The  FAD  process 
combines  data  blocks,  from  the  sender  widi  acknowledgments  from  die  Receiver,  into  complete  !• 
frames.  It  sends  die  I-frames  to  die  FAD  of  die  odier  process.  The  FAD  also  parses  received  I- 
frames  from  the  other  FAD  and  sends  the  adoiowfedgment  to  die  Sender,  and  data  blocks  to  die 
Receiver. 

DTE  DCE 


Figure  43 :  Processes  for  the  Information  Transfer  Phase 
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•  Model  1:1- frames  only 

I-frunes  are  repressed  in  the  foim  where  n  is  die  send  sequence  number  N(S), 

and  m  is  die  receive  sequence  nmnberNCR).  The  message  “U”  is  a  data  Mode  sent  from  die  Smder 
to  the  FAD,  (M*  finnn  the  FAD  to  the  receiver.  It  is  this  data  block  vdiicii  is  {daced  in  or  udeen  from, 
the  I-frame.  The  ‘i’  in  “Di”  is  the  send  sequence  number.  The  message  “Ai”  is  an  admowledgmait 
with  a  receive  sequence  number  of  ‘i*.  The  finite  state  machines  for  the  Sender,  Receiver  and  FAD 
of  the  DTE  are  shown  in  Hgures  44, 45,  and  46.  The  FSMs  for  die  DCE  are  die  same  with  a  2 
substituted  for  1  wherever  it  occurs.  Since  no  RR-frames  are  used,  I-frames  can  only  be 
adoiowledged  by  receiving  an  N(R)  frmn  an  incoming  data  fiame. 

•  Modd  2: 1  -  frames  and  RR*s 

If  the  DCE  does  not  have  any  user  data  blocks  to  send,  it  is  not  aide  to  acknowledge 
the  reedpt  of  die  DTE  I-frames.  fo  this  case,  the  DTE  should  stop  sending  frames  after  it  readies 
the  window  limit 

The  solution  to  this  problem  is  the  Receive  Ready,  or  *‘RR”  message.  It  is  an  S- 
frame,  containing  no  user  data  block,  but  does  contain  an  acknowledging  sequence  number.  Its 
puipose  is  to  infoim  the  receiving  process  (DTE  in  this  case)  diat  the  sending  process  QXE)  is 
ready  to  receive  the  I-frame  numbered  N(R):  it  acknowledges  I-frames  up  to  N(R)  -  1.  The 
Receiverl  vrith  I  and  RR  frames  is  shown  in  Figure  46.  The  FAD  with  RR  fiames  are  specified  by 
dashed  transitions  in  Hgure  47. 

In  the  Receiverl  diere  are  now  two  types  of  acknowtedgment  messages:  ‘*ACKi,” 
and  “Ai,”  for  i  =  0, 1 , 2;  in  the  first  model  we  had  only  “Ai”.  This  is  to  allow  for  two  different  ways 
of  acknowledging  I-ftames  by  the  Receieverl  process:  by  I-fiames  or  by  RR-frames. 

When  the  FAD  process  has  data  to  send,  it  queries  the  Receiver  by  sending  an 
“ENQ”;  diis  insures  that  the  latest  N(R)  is  soit  along  with  the  I-ftame.  These  enquiries  are  answered 
by  an  “Ai"  message.  But  if  the  FAD  process  has  no  data  to  send,  it  has  no  way  of  knowing  whedier 
any  I-frames  have  been  received  and  need  to  be  acknowledged.  This  is  the  purpose  of  the  “ACKi” 
messages;  to  allow  die  Receiver  to  initiate  an  adoiowledgment 
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Figure  46 :  Receiver  1  of  LAP-B  Protocol  (I  and  RR  Frames) 

For  the  automated  analysis,  the  FSMs  in  Hguies  44,45,46  and  47  are  converted  to  a 
text  file  and  entered  into  program.  The  transition  names  in  this  text  file  ate  the  same  as  in  the  FSM 
diagrams  except,  transition  arc  “ACKi”  is  represoited  as  “ACi.” 

The  program  was  tun  witfi  two  differmit  input  files  the  LAP'S  protocol  with  I*fiames 
and  LtqvB  protocol  with  I  and  RR  frames.  At  the  end  of  analysis  69102  states  fiom  the  L^B 
protocol  wifii  I-frames  were  generated  and  analyzed.  No  unspedfied  receptions,  unexecuted 
transitions  or  diannel  overflows  were  discovered.  The  maximum  channel  length  was  6. 

A  deadlock  condition  was  found  at  state  16817.  All  charmels  were  empty  and 
Senderl,  Receiverl,  FADl,  FAD2,  Saidet2,  Receiver2  were  in  states  3, 3, 1, 1, 3, 3  respectively. 
The  state  deadlock  was  expected  since  RR-fiames  were  not  included  in  this  analysis.  The  main 
differmce  between  the  analysis  results  with  supertrace  and  ttie  full  state  analyds  of  die  protocol 
[BULB93],  is  the  number  of  states  generated  and  analyzed.  The  number  of  states  generated  with 
full  state  search  algorithm  was  73391.  The  supertrace  algorithm  generated  almost  95%  (69102/ 
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73391 «  0.941)  of  all  the  states.  The  size  of  die  memory  is  a  aitical  factw  in  die  ^nention  of 
collisions.  The  algorithm  (novides  better  coverage  widi  a  larger  hash  taUe  and  effective  haidi 
funcdorL 

In  the  analysis  of  die  same  [Hotocd  utilizing  the  r^ular  mushroom  imigram,  the 
deadlock  was  detected  at  state  number  17034.  The  difference  of  217  states  betweoi  die  two 
programs,  does  not  necessarily  mean  that  217  collisions  occurred.  It  is  possiUe,  though  not 
probable,  that  (me  coUusioi  occurred  and  216  successor  states  were  never  consictered.  We  do  know 
that  the  number  of  collusions  is  between  1  and  2 17.  It  should  be  emphasized  that  die  purpose  of  the 
supertrace  program  is  not  to  produce  a  total  coverage  of  states.  The  purpose  is  to  validate  diose 
network  protocols  through  a  controlled  partial  search  which  cannot  be  exhaustively  analyzed. 

The  LAP-B  Protocol,  including  RR-frames,  was  also  analyzed.  The  program  could 
not  complete  the  analysis  due  to  insufficient  memory.  At  the  point  of  termination  300456  global 
states  had  been  generated  and  analyzerL  No  unspecified  receptions,  deadlocks  or  channel  overflows 
were  recorded  for  the  analyzed  portion  of  the  protocol.  The  maximum  channel  size  reached  was  5. 
The  number  of  states  goierated  with  regular  mushroom  {nogram  on  the  same  {notocol  was  1S3S6S 
[BULB93].  These  results  clearly  show  the  improvement  of  die  su{)ertrace  algoridim  0{)tion  over  the 
regular  mushroom.  146891  more  states  are  generated  and  analyzed  by  Supertrace  algoridun.The 
96%  increase  in  the  number  of  states  analyzed,  is  a  clear  indicaticm  of  the  im[novement  of  the 
Su{)eitrace  algorithm  over  regular  Mushroom  program.  A  sample  in{>ut  for  LAP-B  protocol  with  I 
and  RR  fiames  and  partial  analysis  results  are  shown  in  A{qpendix  A. 

2.  SCM  Model  With  Supertrace 

There  are  a  few  programs  specified  formally  by  SCM  model  which  have  been  analyzed 
by  Big  mushroom  program  in  [BULB93].  The  same  specifications  will  be  used  to  make  a 
com[)arison  of  regular  and  big  mushroom  with  su{)ertrace. 

a.  Go  Back  N  Protocol 

The  protocol  selected  for  analysis  is  a  one  way  data  transfer  {notocol  with  a  variable 
window  size,  which  is  essoitially  a  subset  of  die  High-Level  Data  Link  Contiol(HDLQ  class  of 
protocols.  This  model  is  modeled  and  analyzed  in  [LUND91][BULB93].  The  same  specification 
with  differmit  window  sizes  was  used  to  com{)are  the  su{)eitrace  and  exhaustive  search  algoridims. 

The  summary  of  the  s{)ecification  is  explained  below.  There  are  two  machines  in  the 
system,  a  sender  (my)  and  a  receiver  (m2).  The  solder  soids  data  blo<hs  to  the  receiver,  which  are 
numbered  sequentially,  0,  1 . w,  0,  1, ...  for  a  window  size  of  w.  As  in  HDLC,  the  maximum 
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number  of  data  Modes  which  can  be  sent  without  receiving  an  admowledgment  is  w,  die  window 
size.  The  receive,  m2,  receives  the  data  Modes  and  acknowledges  them  by  sending  die  sequence 
number  of  die  next  data  Mode  expected  (wMch  is  stored  in  local  vaiiaMe  expel).  The  shared 
variables  DATA  and  are  used  to  pass  messages  from  sender  to  receiver,  and  the  shared  vaiiaMe 

ACK  is  used  to  pass  acknowledgments  back  to  the  sender.  The  receiver  may  acknowledge  any 
number  of  Mocks  received  up  to  the  window  size.  Upon  receiving  the  acknowledgment,  the  seiuto 
must  be  able  to  deduce  how  many  data  blocks  are  being  acknowledged.  This  is  done  by  observing 
the  difference  between  the  values  of  the  received  admowledgment  and  the  sequence  number  of  the 
last  data  blocks  sent 

The  general  qiedfication  of  the  protocol  is  given  in  Figure  48  and  in  Table  6. 
Initially,  both  sender  and  receiver  are  in  state  0,  arrays  DATA  and  SEQ  are  empty,  and  ACK  is 
empty.  The  domains  of  DATA,  Rdata  and  Sdata  are  not  spedfied;  diese  are  used  to  hold  user  data 
blocks.  Sdata  and  Rdata  are  the  interface  or  access  points  of  the  Mgher  layer  protocol.  The  local 
variables  for  the  sender  are  Sdata,  used  to  store  data  blocks,  seq,  used  to  store  the  sequence  number 
of  the  next  data  Mode  to  be  soit  out,  and  i,  used  as  m  index  into  HhtDATA  and  SEQ  arrays.  Initially 
seq  is  set  to  0,  and  i  is  set  to  1.  The  local  variables  of  the  reedver  are  Rdata,  exp,  and  j.  Rdata  is 
used  to  receive  and  store  incoming  data  blocks,  exp  to  hold  die  expected  sequence  inimber  of  the 
next  incoming  data  block,  and  y  is  an  index  into  the  shared  arrays  DATA  and  SEQ. 

There  are  four  basic  types  of  transitions.  In  the  sender,  ml,  the  -D  transition 
transmits  a  data  Mock  by  placing  it  into  the  shared  variable  DATAfO,  and  die  sequence  number  into 
SEQ(i).  The  send  is  enabled  whenever  those  variables  are  empty.(The  interactiem  between  the 
sender  and  die  user,  or  Mgher  layer  is  not  specified  here).  The  inc  operation  inciemoits  its 
arguments,  if  less  than  their  maximum  value,  in  wMch  case  it  resets  them  to  the  minimum  value. 
The  operator  ""  0  represents  the  inc  operation  repeated  k  times,  if  the  argument  is  k  and  the 
symbol  £  denotes  the  empty  value.  The  receive  transition  in  the  receiver,  m2,  is  enabled  whatever 
a  data  Mock  of  the  tqipropriate  sequoice  number  is  in  the  Jth  element  of  DATA  and  SEQ.  An 
acknowledgment  may  be  sent  by  m2  in  any  state  except  0,  in  wMch  case  no  acknowledged  data 
blocks  have  been  received. 

The  remaining  transition  is  the  +Ak  receive  acknowledgment,  in  ml.  If  ml  is  in  state 
u,  1  ^  u  ^  w,  and  there  is  nonempty  value  in  shared  variable  ACK,  that  exactly  one  of  the 
transitions  +A0,  +A1,  ...,  4-Aw-l  will  be  enabled;  it  will  be  that  Ak  sudi  that  the  predicate 
ACK  ©  ^  =  seq  is  trae,  and  the  next  state  is  k[LUND91]. 
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seq  :  (0. 1. 2.  ...  .w)  exp  :  (0. 1, 2 . w) 

i  '.(1.2.3 . w)  j  :(i,2 . w) 

Figure  48 :  State  Machine  and  Variables  of  the  Go-Back-N  Piotocol 


TABLE  6:  PREDICATE  ACTION  TABLE  OF  GO-BACK-N  PROTOCOL 


For  analyzing  this  protocol  by  Big  Mushroom  with  Supertrace  program,  the  inputs 
to  the  program  should  be  completed.  These  consist  of  a  text  file  description  of  FSMs,  the  package, 
definitions,  which  include  the  variables  of  the  protocol,  and  the  subprograms 
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AiuUyte^Predicate_Machines  and  Action^  wMch  define  the  predkau-action  table  and 
OutpmJjtuple  procedure,  which  defines  the  ou^iut  foimat  for  foe  global  tij{des,  must  be  enleied. 
The  user  should  also  write  foe  Global  Jmh  function  in  Ada  Programing  language  foat  covers  local 
and  shared  variables  and  machine  states  of  the  i»otocol.  Completed  packages^rooedures  and  global 
hash  function  for  a  window  size  of  10  are  given  in  Appendix  B. 

The  same  names  are  used  for  local  and  shared  variables  in  the  package  definitions  as 
in  the  predicate-action  table.  Variables  DATA,  ACK  and  Sdata  are  declared  as  one  dimensitmal 
array  of  window  size.  Lxx:al  variables  and  exp  and  index  numbers  /  andy  are  declared  as  integers 
in  the  range  0  to  window  size.  Global  variable  ACK  is  declared  as  integer  in  the  range  - 1  to  window 
size,  where  - 1  represents  e  value  in  the  predicate  action  taUe.  An  enumeration  type,  bi0er_type,  is 
declared  for  storing  the  data  passed  by  foe  upper  layer  to  local  variable  Sdata.  Data  are  declared  as 
dO,  dl, ...,  d9,e,  where  e  represoits  foe  e  value.  Transition  names  in  the  spedfication  are  defined  as 
sendjiata,  rcv_data,  sndjack,  Rcvjicki  for  -D,  +D,  -A.  and  +Ai  in  predicate-action  table 
respectively. 

The  global  state  analysis  of  Go-Back-N  protocol  wifo  different  window  sizes  was 
conducted  by  both  Big  Mushroom  and  Supertrace  algorifoms.  The  mimber  of  global  states 
goierated  in  foese  programs  is  listed  in  Table  7  CWS”  represents  the  window  size).  In  the  analysis 
of  the  Go-Back-N  protocol  wifo  a  window  size  of  18,  Big  Mushroom  program  was  interropted  due 
to  a  memory  error  and  could  not  complete  the  analysis.  No  deadlodcs,  unexecuted  transitions  or 
Channel  overflows  were  encountered  in  the  analyzed  portion  of  foe  protocol.  The  comparison  of 
foese  results  and  the  advantages  of  Supertrace  algorithm  will  be  discussed  in  Chapter  V. 

TABLE  7:  THE  NUMBER  OF  STATES  GENERATED  WITH  BIG  MUSHROOM  AND 

SUPERTRACE  ALGORITHM 


GBN  Protocol 

WS«10 

WS»12 

WS=13 

WS=14 

WS=18 

Big  Mushroom 

31460 

70980 

101920 

142800 

161431 

Supertrace 

30632 

66654 

90210 

122880 

Coverage  of  Super¬ 
trace 

97% 

94% 

89% 

86% 

Unknown 

b.  Token  Bus  Protocol 

Another  example  of  foe  program  application,  foe  token  bus  specification  in 
[CHAR90]  will  be  used.  The  specification  is  a  simplified  one,  which  will  be  used  to  dmonstrate 
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the  coverage  of  Supeitrace  algoiidun  fw  protocols  wifli  small  number  of  states.  It  assumes  dut  the 
transmissimi  medium  is  eiror  free  and  all  trananitted  messages  are  received  undamaged.  Hie  ^obal 
state  analysis  is  generated  from  this  tokoi  bus  specification  for  a  protocol  omsisting  of  8  machines. 

The  specification  of  the  protocol  is  given  in  Figure  49  and  TaUe  8.  The  FSM 
diagram  and  the  local  variables  are  the  same  for  each  machine,  where  die  transition  names:  ready, 
rev,  pass,  get-tk,  pass-tk,  Xmit,  and  moreD  are  af^iended  with  the  coire^nding  machine  number 
to  die  end  of  each  machine  in  the  specificatioa  This  makes  it  easier  to  follow  die  leachalxlity 
graphs.  The  remainder  of  the  protocol  specification  as  described  in  [CHAR90]  is  as  follows:  The 
shared  variable.  MEDIUM,  is  used  to  model  the  bos,  which  is  “shared”  by  eadi  machine.  A 
transmission  onto  the  bus  is  modeled  by  a  write  into  the  shared  variable.  The  fields  of  this  variaUe 
correspond  to  the  parts  of  the  transmitted  message:  the  first  field.  MEDIUM.!,  takes  the  values  T  or 
D,  which  indicate  whether  die  frame  is  atoken  or  adata  frame.  The  second  field  contains  the  address 
of  die  station  to  which  the  message  is  transmitted  (DA  for  “destination  address”):  the  next  field,  die 
originator  (SA  for  “source  address”);  and  finally  the  data  block  itself. 

The  network  stations,  or  machines,  are  defined  by  a  finite  state  machine,  a  set  of  local 
variables,  and  a  predicate-action  table.  The  initial  state  of  each  machine  is  state  0,  and  the  shared 
variable  is  initially  set  to  contain  the  token  with  the  address  of  one  of  the  stations  in  the  “DA”  field. 

The  value  of  local  variable  next  is  the  address  of  the  next  or  downstream  neighbor, 
these  are  initialized  so  the  entire  network  forms  a  cycle,  or  logical  ring. 

The  local  variable  i  is  used  to  store  the  station’s  own  address.  As  implied  by  the 
names,  the  local  variables  inbufzoA  ombitfan  used  for  storing  data  blocks  to  be  transmitted  to  or 
retrieved  from  other  machines  on  the  network.  The  latter  of  diese,  oud>itf,  is  an  array  and  thus  can 
store  a  potentially  large  number  of  data  blodrs.  The  local  variable  ctr  serves  to  count  the  number  of 
blocks  sent;  it  is  an  upper  bound  on  the  number  of  blocks  which  can  be  sent  during  a  single  token 
holding  period.  The  local  variable  j  is  an  index  into  the  array  outbuf. 

The  local  variables  j  and  ctr  are  initially  set  to  1,  and  inbuf  and  outbid  ast  initially 
set  to  empty.  The  shared  variable  MEDIUM  initially  contains  the  token,  with  the  address  of  the 
station  in  the  DA  field.  Thus  the  initial  system  state  tuple  is  (0, 0, ....  0)  and  the  first  transition  taken 
will  be  getjk  by  the  station  whidi  has  its  local  vari^le  i  equal  to  MEDIUM.DA. 

Each  machine  has  four  states.  In  the  initial  state,  0,  the  stations  are  waiting  to  either 
receive  a  message  from  another  station,  or  the  tokm.  If  the  token  appears  in  the  variable  MEDIUM 
with  the  station’s  own  address,  the  transition  to  state  2  is  takm.  When  taking  the  get-tk  transition, 
the  machine  clears  the  communication  medium  and  sets  the  message  counter  c/r  to  1.  In  state  2,  tire 
station  transmits  any  data  blocks  it  has  moving  to  state  3,  or  passes  the  token,  returning  to  state  0. 
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state  3,  the  statkm  wiU  return  to  statB2  if  any  addittonal  blodcs  are  to  be  seat,  until  the  auudmum 
count  k  is  readied,  or  uiien  all  ttie  statiiMis’ messages  have  been  sent,  ttie  statfam  retums  to  stale  0. 


Hgure  49 :  FSM  and  Variables  of  Token  Bus  Protocol 
The  receiving  station,  as  widi  all  stations  not  in  possession  of  die  token,  will  be  in 
state  0.  The  message  will  s^pear  in  MEDIUM,  widi  die  receiving  station’s  address  in  the  DA  field. 
The  receiving  transition  to  state  1  will  then  be  takoi,  the  data  blodr  copied,  and  MEDIUM  cleared. 
By  clearing  the  medium,  the  receiving  station  enables  die  sending  station  to  return  to  its  initial  state 
(0)  or  to  its  sending  state  (2). 


TABLE  8:  PREDICATE  ACTION  TABLE  FOR  TOKEN  BUS  PROTOCOL 


Transition 

Enabling  Predicate 

Action 

rev 

MEDIUM.(a)A)=(D,i) 

inbuf MEDIUM.(SA,data) 

ready 

true 

MEDIUM  :b0 

get-tk 

MEDIUM.(U)A)*ai) 

MEDIUM:b  0; 
ctr:=  1 

pass 

outbuflj]  B  0 

MEDIUM (  T,  next,  i,  0) 

TABLE  8:  PREDICATE  ACTION  TABLE  FOR  TOKEN  BUS  PROTOCOL 


The  symbol  “0”  indicates  that  the  variable  should  be  incremented  unless  its 
maximum  value  has  been  reached,  in  \riuch  case  it  should  be  reset  to  die  initial  value.The  notation 
MEDIUM.(t.  DA)  is  used  to  denote  the  first  two  fields  of  the  variable  MEDIUM.  For  example, 
MEDIUM.(t,  DA)  3  (T,  i)  is  a  boolean  expression  uriiich  is  true  if  and  only  if  the  first  fields  of 
MEDIUM  contains  the  value  T,  and  the  sectmd  field  contains  the  value  i.  Other  notations  in  the 
predicate-action  table  are  intuitive. 

The  same  names  as  in  the  specification  are  used  for  the  local  and  global  variables  in 
the  package  definitions.  Also,  the  “empty”  value  is  represented  by  “E”  and  the  data  are  represented 
by ‘T*  in  this  package.  The  upper  bound  on  the  number  of  the  data  blocks  in  the  oudn/ variable  is 
set  to  7. 

The  results  are  same  with  the  previous  analysis  results  [BULB93].The  global  state 
analysis  with  supertrace  has  generated  263  global  states  and  diere  were  no  deadlocks  or  unexecuted 
transitions. 

B.  Automated  Test  Generation  Of  FDDI  Protoctri  By  ^TESTGEN*’  Pit^ram 

In  this  section  an  automated  test  generation  of  the  FDDI  protocol  is  illustrated.  FDDI  is  a 
standard  for  a  lOOMb/s  fiber  optic  network  which  has  come  on  the  market  in  the  last  few  years.  The 
protocol  was  formally  ^redfied,  including  timing  requirements,  and  verified,  in  [LUND90B].  The 
same  specification  of  FDDI  protocol  will  be  used  in  this  section  The  brief  description  of  the  FDDI 
protocol  is  givoi  below. 

The  protocol  specification  consists  of  the  FSM  description  of  each  machinej^gure  50;  tire 
predicate-action  table  (Table  9);  and  the  timer  specifications  (not  shown).  A  detailed  description  of 
protocol  t^ipears  in  [LUND90B],  so  here  we  give  only  a  brief  description 

Each  machine  shares  one  variaUe  with  its  upstream  neighbor  (called  inbuf)  and  one  witii  its 
downstream  neighbor  (called  outbitf).  (These  shared  variables  serve  as  the  input  and  ouqrut  ring 
cormections). 
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Tbe  FSM  consists  of  20  stales.  In  states  0-7  die  statton  has  nolhiiig  to  tnnsmit,  so  is  merely 
waiting  for  die  ttdcen  and  processing  it  hi  states  10-21  the  station  lire  a  message  to  trensmit,  nd 
does  so  iqion  receiving  die  token.  The  tnmsidon  names  (Ml  die  transition  arcs  serve  re  a  key  into  the 
PAT.  which  specifies  the  acdon  taken  when  the  transidon  is  executed. 

There  are  two  transidons  ^ledfied  in  the  TaMe  9  which  are  not  diown  in  the  state  diagram; 
diis  is  because  these  transitions  can  be  taken  fitun  any  state.The  TRT-watch  transition  becomre 
enabled  whenever  the  TRT  timer  expires.  This  transiticMi  immediately  resets  the  timer,  and 
increments  variable  Late-cnt.  The  second  transiti(Mi  not  shown  is  called  CRASH;  diis  is  the 
termination  of  the  ring  operation,  which  occurs  if  the  token  fails  to  circulate  widiintwk^theTTRT. 


Figure  50 :  FSM  of  the  FDDI  Protocol 
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TABLE  9:  PREDICATE  ACTION  OF  THE  FDDI  PROTOCm 


Ikuisiiioii 

KiMhiiiig  predicate 

Action 

PDU-Q 

A-t)iif(i)9k0vS-bafa)^0 

token 

inbof[1..7]  -  a.  J.  K.  0. 0,  T.  T) 

inbu£>0;  S-cnt>0 

early 

Laie-cntaO 

THT-val  TRT-val; 

TRT-val  :>iT-Opr 

late 

Laie-cnt  >0 

Laie<nt>0; 

pass-tk 

IRUE 

ootbuf[1..7] :« (I.  J.  K.  0. 0.  T.  T) 

rcv-F 

inbuf[5]  €  { 1. 2}  A 
inbuf[6..7]  =  MA 

in>  1 

q>-ipt 

inbaf[inl  teT 

msg-l>ufIin],oud)iif[in]:>  inbuflin]; 
in>iiH-l 

T 

inbuf[in]  =  T 

ontbufOn]  :>  T,  iiibaf  :m  0; 
in :« in  -f  1 

end-F 

TRUE 

oud)uf[in^  1  jn+2]:s 
(esr4nbaf[iM-l4n+2]) 

ack 

TRUE 

ondwfnn,  iiH-1,  iM>2] (err,  1. 1) 

pass-F 

inbufIS]  e  { 1, 2}  a 
inbufld..?]  9tMA 

in:*  1 

repeat 

inbuf[in]  *T 

oudNifOn]:*  inbufljm];  in  :*  infl 

X-Syn 

S-4Riftj.oat]  #  0 

oudHiflout]  :*  S-bnfU^]; 
out:*out-4>l 

X-Asyn 

A-bof[i^t]  ^  0  A 

(S-cnt  =  max  v  S-buftj]  =  0  ) 

outbuflout]  :*  A-biif[i^t]; 
one*  outf  1 

end-S 

S-biifIj,oat]  =  0 

oiidHif[ouM)ut-f  l^-t-2]  :*  (T,0,0); 
S<€ntJ>-cnt  S-cnt4-l; 
j.oiit:*  j  ©  1,1 

end-A 

A-buf[i,out]  =  0 

oatbufIouM>ut-(-l, out-1'2]  :*  (T,0,0); 
F-cnC*  F-cnt-t-l;  i,  out  :*  i  ©  1 , 1 

next-S 

S-cnt  <  max  a  S-buf[]l  ^  0 

next-A 


THT-val  >  0  A  A-biif[i]  ^  0 


strip 


inbuf[6..7]  =  MA  A  F-cnt  >  0 


clear 


F<nt  =  0 


TRT-watch 


TRT-val  =  0 


Laie-cnt  >  1 


TRT-val :»  T-<^ 
Late-cm LatcHait-i-l 

terminate  ring  operation 


CRASH 


L  Creating  the  FSM  And  Predkate*AclioQbipiitFDcf  for  the  FDDI  Protocol 

Creation  of  the  FSM  inpm  file  is  a  straightftnrwaid  process.  The  user  should  nimber  aU 
tnnsitkNis  on  die  finite  state  madiine  as  shown  in  Hgnre  50.  All  tiansiti«is  should  be  written  to  a 
ii^  text  file  accoiding  to  the  niles  in  Chi^r  IV.  The  FSM  input  file  for  die  FDDl  protocol  is 
showninHgureSl  and  Predicate-action  ii^xit  file  is  shown  in  Hgure  52. 

Some  of  the  relational  symbols  in  die  Predicate-Action  Table  are  convened  to  dieir 
semantically  equivalent  text  forms.  Fbr  example  reladonal  symbols  a  .  v  areconvmtedto“and’* 
and  “or”  respectively.  A  relatively  more  complex  symbol  i:s  i  0  1  is  rqiresented  as  “i  :s 
l(mod+)l.” 

The  TESTGEN  program  first  prints  out  all  die  paths  in  the  inotocol.  It  also  finds  all  die 
cycles  and  checks  them  for  a  transition  diat  will  ultimately  lead  back  to  the  initial  state.  All  possdde 
paths  in  the  FDDI  protocol  are  output  to  a  file  as  shown  in  Figure  53.  The  paths  are  dqiicted 
according  to  the  numbers  assigned  by  die  user. 


0 

oil  token 
022  rev-f 
033  paaa-f 
0  10  4  pdu-q 
145  early 
156  late 
227  cp-rpt 

2  6  •  t 

339  repeat 

3  7  10  t 

4  0  11  paaa-tk 

5  0  12  paaa-tk 

6  0  13  ack 

7  0  14  and-f 
10  11  15  token 
10  12  16  rev-f 

10  13  17  paae-f 

11  14  18  early 

11  15  19  late 

12  12  20  cp-rpt 

12  16  21  t 

13  13  22  rapeat 

13  17  23  t 

14  14  24  x-ayn 

14  18  25  end-a 

15  15  26  x-ayn 

15  19  27  end-a 

16  10  28  ack 

17  10  29  end-f 

18  14  30  next-B 
18  18  31  x-aayn 

18  20  32  end-a 

19  15  33  next-a 

19  21  34  paaa-tk 

20  18  35  next-a 

20  21  36  paaa-tk 

21  21  37  atrip 
21  0  38  clear 


Hgure  51 :  FSM  Iiqnit  Rle  of  FDDI  Protocol 
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pdu-q 
tok«B 
•■rly 
lat* 
pua-tk 
rcv-f 
cp-rpt 
e 

•od-f 
•ek 
paaa-t 
rapaat 

X'ayn 
x-aayn 
and-a 
aod-4 
naxe-a 
naxt-a 
aerlp 
claar 
crt -watch 
craah  I 


a-buf(l)  /■  0  or  a-tau((j)  /•  0 
1iiIm((1..7)  .  (l.l.k.O.O.t.c) 
latwcac  ■  0 
lata-cnt  >  0 
trua 

inbut  •  (x.x.x,x.lor2,aa) 

I  tobufdn]  /a  t  I  aag-bwflin] 

a  t 

trua 

trua 

iobul  a  (x.x,x.x>lor2,/aaa) 
InbuCCta]  /a  t 
8-buf(j,out]  /a  0 


I  no 

I  Inbuf  ta  0  t  a-cat  la  0 
Itht-val  la  Crt-val  i  trc-val 
I  lata-enc  la  o 
I  autbuf(l..7)  la  (t, j.k.o.o.t.t) 
I  in  la  1 

la  InbufClnl  i  outbufCln] 

I  ouebufUnl  la  t  i  inbuf 
I  outbuf Cln,ln*l,ln*3]  la 
I  outbuf (ln.la*l.ln*21  ta 

I  in  ta  1  I 

I  outbufCinl  la  inbuflin] 


t-opr 


I  a  inbuf (ini  I  in  I  a  inal  I 
la  0  I  iu  ta  inai  1 

(arr.inbuf (inal,ina21 )  I 
(arr.l.l)  I 

in 


inal  1 

I  outbuflout]  ta  a-buf[j.out)  t  out  ta  outat  I 
a-buf(i.out)  /a  0  and  (  a-cnt  a  aax  or  a-buf(J]  a  o  )  I  outbuftoucl  la  a-buf  (i.outl  loutiaoutall 
8-buf[j>outl  a  0  I  outbuf (out,outal.outa2l  ta  (t.0.0)  I  a-cnt  ta  a-cntal  i  f-cnt  la  f-cntal  I 
a-buf[l,outl  a  0  I  outbuf (out,outal,outa2)  ta  (t,0,0)  t  f-cnt  ta  f-cntal  I 
a-cnt  <  nax  and  a-bufCj)  /a  o  I  no  I 

tht-val  >  0  and  a-buf(l]  /a  o  I  no  I 

inbuf (6.. 7)  a  aa  and  f-ent  >  0  I  inbuf  ta  o  t  f-cnt  ta  f-cntal  I 
f-cnt  a  0  I  no  I 

I  trt-val  a  0  I  trt-val  ta  t-opr  •  lata-cnt  la  lata-cntal  I 

lata-cnt  >1  I  no  I 


Hguit  52 :  Predicate  Action  bipot  Rle  of  FDDI  Protocol 
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Hgure  53 :  The  R^resentation  of  Padis  in  the  Ou^t  Rle  for  the  FDDI  Protocol 
In  our  example,  the  number  of  paths  found  by  the  TESTGEN  program  is  162.  There  are 
no  cycles  without  an  outgoing  transition  diat  leads  back  to  die  initial  state. 

Hnally,  the  TESTGEN  program  creates  the  testing  sequence  table  by  printing  all  possible 
transition  sequences,  excluding  continuous  cycles.  The  table  is  21 12  lines  long.  Since  the  size  of  die 
table  generated  for  the  FDDI  protocol  is  too  big  to  show  here,  it  is  partially  depicted  in  Figure  54. 

Each  of  these  21 12  ouqxit  lines  corresponds  to  a  single  test  In  Hgure  55  only  the  first 
few  test  are  shown.  The  width  of  die  table  corresponds  to  the  number  of  iiqiut  and  ouqnit  variables. 
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For  example,  consider  the  first  test  in  Hguie  55.  The  start  state.  Si,  is  state  0;  the  aid  state,  Sg,  is 
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sttfB  1.  The  input  vaiiables  must  be  set  lo  the  values  shown  on  tiie  left  side  of  the  tftde.  and  die 
output  variablea  are  expected  to  tdce  on  die  values  ^wn  on  the  ride.  The  nut  test  will  take 
a8tt)striB4. 

If  a  vaiiaUe  is  bodi  input  and  output  it  is  maiked  by  (i)  for  h^ut  red  (o)  for  output 
variatde  to  riiow  their  status  in  the  generated  test  se^ience.  For  example.  late_coimt  appears  both 
in  the  oiabling  indicate  and  in  the  action  part  of  transition  It  is  both  an  iiqiut  and  oiripot 
vaiiaUe  and  is  thus  rejnesented  in  the  oufout  test  sequence  as  late_cnt(i )  and  bue_cnt(o)  as  in  Figure 
54. 

If  diere  is  more  than  one  clause  in  the  enabling  predicate  part  of  the  predicate  action  table 
the  TESTGEN  program  generates  one  test  sequence  and  marks  die  variables  of  this  test  with  the 
clause’s  relational  symbol.  In  our  example  enabling  predicate  for  die  PDU-Q  transition  consists  of 
two  clauses.  The  TESTGEN  {uogram  illustrates  dds  by  putting  the  relational  symbol  **0^* 
(relational  symbol  in  this  case)  in  fiont  of  the  values  to  be  compared  in  die  output  file.  The  values 
for  a-buf(or  l^empty)  and  s-bt4  (orlstempiy)  should  be  read  as  “A-buf  is  not  equal  to  empty  ot  S- 
buf  is  not  equal  to  empty."  It  is  the  responsitxlity  to  the  user  to  change  the  variaUes  for  diat 
transidon  to  enable  that  transition.  For  testing  purposes,  the  user  can  either  make  one  or  both  of 
these  two  vaiiaUes  ncm-empty. 

If  diere  are  more  than  two  clauses  in  die  enatding  predicate  part  of  die  FAT  as  mentioned 
in  Chapter  IV,  the  TESTGEN  program  is  able  to  rqiresent  these  clauses  in  the  oufout  test  sequence 
table.  In  die  FDDI  PAT  (TABLE  9),  the  X-Asyn  transition  has  more  dian  two  clauses  in  die  format 
“first  clause  relational  symbol  (second  clause  relational  symbol  third  clause)."  The  TESTGEN 
program  shows  this  in  the  ouqmt  sequence  by  potting  the  relational  symbol  in  parentheses  to 
represent  the  symbol  between  die  second  and  third  clauses,  and  placing  the  first  relational  symbol 
without  paroitheses  in  die  output  file.  For  example,  the  a-bi^i,out]  has  a  value  '"=1  empty”  s-buf 
has  a  value  ”{or)empty”  and  s-count  has  a  value  ”(or)  maai'  in  the  goierated  test  sequence.  This  test 
sequence  input  should  be  read  as  ”A-bufIi,oiaI  should  not  be  empty  and  either  5-cft/  should  be  equal 
to  max  or  S-bitflj]  should  be  empty.” 

The  TESTGEN  program  can  detennine  some  transitions  which  make  a  state  transient  It 
informs  the  user  by  printing  out  a  warning  to  the  terminal  and  output  file.  In  our  example,  the 
TESTGEN  detects  ”end-f'  and  ”ack”  transitions,  which  makes  states  6, 7, 16  and  17  transient  and 
prints  out  a  warning. 

Since  the  TESTGEN  program  generates  all  possible  transition  sequoices,  returning  to 
the  initial  state,  protocol  testing  can  be  executed  by  following  die  order  of  tests  in  the  test  sequence 
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file.  This  means  that  there  is  no  need  to  filnd  the  UIO  (unique  ieput-ouqtut)  sequmice  after  each 
individual  test,  but  only  at  the  end  of  die  last  test  (or  possiUy  not  at  all). 

Finally,  the  TESTGEN  program  also  detects  converging  tiansitians,  if  any,  md  prints  oitt 
the  list  of  the  converging  transidcms.  In  the  case  of  FDDI  protocol,  pass-tk  is  detected  as  a 
(xmverging  state  from  states  4-S  and  also  from  states  19-20.  The  test  designer  should  be  aware  of 
this  as  a  possiUe  source  of  problems  in  die  execution  of  tests. 
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VL  CONCLUSION  AND  FURTHER  RESEARCH  FOSSIBIUTIES 


In  ttiis  chapter  both  software  tools’  cifMbilities  are  summarized  and  further  research 
possiUlities  are  discussed. 

A.  Supertrace  Algorithm 

In  the  first  part  of  this  thesis  a  software  tool  has  been  described  which  imixoves  the  autnnatic 
analysis  of  protocols  specified  by  the  CFSM  and  SCM  models,  by  using  the  Supeitrace  algorithm. 

This  algorithm  inqxoves  the  coverage  of  protocol  analysis  by  generating  a  larger  number  of 
states  than  regular  mushroom  program.  In  cases  where  exhaustive  seaidi  algorithm  is  infeasiUe, 
fills  can  be  extremely  helpful.  It  also  shows  that  the  mushroom  program  with  siqieftrace  is  capable 
of  covering  up  to  95%  for  protocols  with  1.5  x  10^  global  states.  The  improvemmit  of  file 
Supertrace  algorithm  is  illustrated  in  Hgure  55  and  Figure  56.  The  {notocols  are  represented  in 
atforeviated  form  (i.e.  Gbn  for  the  Go<Back-N  protocol).The  number  of  states  generated  by 
mushroom  with  supertrace  is  between  90%  and  95%  for  protocols  up  to  150000  global  states  and 
around  99%  for  protocols  with  20000  global  states. 
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Protocols  dialyzed 


Hgure  56 :  The  Analysis  Results  of  Stqmirace  and  Big  Mushroom 

The  main  achievement  of  SiqMrtrace  can  be  realized  when  die  memory  ct^Mcity  is 
insuffidem  to  allow  an  exhaustive  analysis.  In  the  analysis  of  Go-Back-N  protocol  widi  a  window 
size  18,  Big  Mushroom  cannot  complete  die  analysis  due  to  insuffident  memory.  The  number  of 
states  analyzed  with  Big  Mushroom  is  161431  and  die  number  of  states  analyzed  widi  Supertrace 
is  290,980.  Since  we  do  not  know  the  total  number  of  global  states  in  this  protocol,  we  can  not 
estimate  the  exact  coverage  established  by  Supeitrace  but  we  do  know  that  it  analyzed  290980  - 
161431  sl29549  extra  states  which  is  80%  more  than  the  number  of  states  generated  and  analyzed 
by  Big  Mushroom.  A  similar  result  is  established  for  protocols  specified  with  CFSM  modd.  The 
analysis  of  Lap-B  protocol  with  I  and  RR  frames  can  not  be  completed  by  Simple  mushroom 
program.  The  number  of  states  analyzed  is  153565.  The  same  spedfication  analyzed  with 
Supertrace  algorithm,  and  generated  300456  states  which  is  95%  more  than  the  number  of  states 
generated  by  Simple  Mushroom. 

The  results  shows  that  Supertrace  algorithm  a{^roximates  an  exhaustive  search  analysis  for 
smaller  protocols  and  gradually  changes  into  a  controlled  partial  search  method  for  larger  protocols. 
The  Supertrace  algorithm  cannot  guarantee  100%  coverage  due  to  possibility  of  imresolved  hash 
conflicts  for  small  protocols.  As  a  partial  search  technique  (for  larger  protocols)  it  is  far  superior  to 
the  exhaustive  search  technique. 

The  analysis  of  protocols  specified  in  CFSM  model  was  conducted  on  a  computer  witii  64 
Mbyte  memory,  the  analysis  of  protocols  ^ledfied  in  SCM  model  was  conducted  on  a  computer 
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wtdi  48  Mbyte  meoKMy.  The  overall  improvement  of  supeitraoe  algorithm  is  baaed  on  these 
availaUe  memory  values.  The  number  of  states  generated  can  be  increased  as  die  amount  of  die 
available  memory  increases.  The  supmtrace  algorithm  uses  a  simide  hash  taUe  for  keeping  track  of 
the  generated  global  states.  Instead  of  keqdng  previously  generated  states  indie  hadi  table,  abash 
value  is  calculated  and  correspmiding  value  in  the  ha^  table  is  set  Each  state  is  chedced  against 
the  hash  table  values  to  determine  if  it  was  previously  generated. 

The  number  of  states  analyzed  and  the  coverage  can  be  significantly  improved  by  increasii^ 
the  hash  table  size  in  the  main  program.The  supertrace  algorithm  is  also  more  efficient  in  speed  dian 
the  exhaustive  search  method,  since  time  spent  in  checking  hash  table  is  constant  (0(1)).  The  total 
processing  time  difference  between  these  two  mrthods  increases  as  die  number  of  global  states 
increases. 

The  number  of  states  analyzed  is  usually  very  large  and  it  is  hard  to  locate  faults  by  manually 
searching  the  ou^t  text  file.  An  improvement  would  be  to  store  the  readiability  analysis  results  in 
the  form  of  a  data  base.  A  query  language  that  allows  die  user  to  easily  analyze  the  results  of  die 
analysis  is  suggested  in  [AGGA87]. 

The  data  structures  can  be  simplified  to  allow  more  efficient  utilization  of  memory  so  the  user 
can  analyze  a  larger  number  of  states  and  obtain  a  mote  accurate  analyas. 

Hnally,  the  mushroom  with  supettrace  is  a  tool  which  will  gready  improve  the  analysis  of 
large  protocols  specified  by  die  SCM  and  CFSM  models  which  cannot  be  analyzed  with  exhaustive 
search  methods. 

B.  TESTGEN  Program 

In  the  sectxid  part  of  diis  thesis  a  software  tool  called  '‘TESTGEN"  was  introduced  which 
automatically  produces  a  sequence  of  conformance  test  for  protocols  specified  by  the  SCM  protocol 
model.  The  purpose  is  to  conduct  conformance  testing  on  implementations.  The  TESTGEN 
program  checks  key  control  points  in  the  protocol  and  informs  the  user  if  it  detects  a  possible  error. 

The  TESTGEN  program  takes  as  input  a  protocol  specified  formally  as  two  separate  text 
files,  one  containing  the  finite  state  machine  part,  die  other  containing  the  predicate-action  table  and 
variables.  It  outputs  test  sequences  beginning  from  the  initial  s  finding  all  transition  sequences, 

excluding  continuous  cycles,  and  generates  tests  for  every  transition  on  the  path  back  to  the  initia' 
state,  so  long  as  diere  is  such  a  path  (whoi  there  is  no  path  back  user  is  warned). 

The  main  achievement  of  the  TESTGEN  program  is  its  rqiplicability  to  protocols  specified 
formally  with  the  SCM  model  which  make  it  possible  for  implementors  and  buyers/users  of 
protocol  implementations  to  automatically  generate  a  set  of  tests,  which  ideally  determine  if  the 
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protocol  implementation  meets  its  specification.  It  was  used  to  generate  test  sequences  for  AeFDDI 
{uotocol  in  Chiqtter  V  and  CSMA/CD  protocol  in  Chapter  m.  It  produced  the  same  te^  sequoice 
goierated  for  die  CSMA/CD  protocol  in  [MILL90].  The  automation  of  the  test  sequence  generatitm 
procedure  TESTGEN  expanded  the  applicability  of  the  procedure  to  laiger  and  more  comidex 
protocols. 

A  second,  broader  puqwse  of  this  work  has  been  to  unify  the  fields  of  protocol  specification, 
testing  and  verification  under  a  single  protocol  model,  systems  of  communicating  machines.  As 
eariier  work  [BULB93]  has  automated  the  verification  process  (to  some  degree),  we  now  have  tools 
for  specification,  verification  and  testing  in  this  protocol  model. 

The  TESTGEN  programs  generates  a  test  sequence  based  on  the  specification  of  die  protocol 
and  a  conformance  test  originated  on  these  t^t  sequences.  It  verifies  that  a  given  implementation 
realizes  all  functions  of  the  original  specification,  over  the  range  of  parameter  values.  If  die 
implementation  under  test  (lUT)  passes  these  t^,  it  is  crqiable  of  reproducing  the  behavior  formal 
specification.  We  do  not  know  if  lUT  will  handle  erroneous  inputs  in  a  manner  consistent  with  the 
original  specification.  Because  conformance  test  sequence  is  used  to  test  the  presence  of  desirable 
behavior,  not  the  absence  of  undesirable  behavior. 

A  further  study  on  this  issue  might  be  the  generadon  of  a  simulator  consistent  widi  the 
specified  protocol  such  that  the  expected  output  values  can  be  calculated  quickly.  Each  step  in  die 
transition  sequence  could  also  be  tested  and  verified  easily.  The  success  of  this  method  will  depend 
on  the  correctness  of  the  simulator  program. 

The  TESTGEN  program  is  originated  from  die  procedure  created  in  [LUND90A].  Furdier 
research  in  diis  area  might  be  to  improve  of  d%  procedure  itself  and  determine  udiat  assumptions 
are  made  ccmceming  the  lUT. 

The  TESTGEN  program  does  not  guarantee  detection  of  all  the  errors  in  the  protocol.  It  does 
represent  an  attempt  to  exercise  all  parts  of  lUT  and  provides  some  assurance  that  the 
implementation  meets  its  purpose  without  obvious  or  easily  detected  errors. 
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APPENDIX  A  (LAP-B  Protocol  Inftnrntttioii  Truufer  Phase) 


Analysis  Results  (I  Frames  Only) 
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69102 . . . 

The  result  of  Lap-B  Protocol  analysis  (I  frames  only) 

StMIARy  OF  itEACHABILITV  ANALYSIS  (ANALYSIS  COMPLETED) 


Total  nundsar  of  states  generated  :  69102 
Number  of  states  analyzed  :  69102 
nuffllaer  ot  deadloclca  :  1 
nuffllser  of  unspecified  receptions  :  0 
maximum  message  queue  size  :  6 

channel  overflow  :N<E6E 
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Lap-B  Protocol  FSM  Tat  File  (I  and  RR  frames) 


start 

ntaatier_of_machinaa  6 
aachine  1 
state  1 
trana  ♦AO  1  3 
trans  -DO  2  3 
state  2 
trans  ♦AO  2  3 
trans  -D1  3  3 
trans  ♦Al  4  3 
state  3 
trans  ♦AO  3  3 
trans  ♦Al  5  3 
trans  ♦Al  7  3 
state  4 
trans  ♦Al  4  3 
trans  -01  5  3 
state  S 
trans  ♦Al  5  3 
trans  ♦Al  7  3 
trans  -02  6  3 
state  6 
trans  ♦Al  6  3 
trans  ♦AO  1  3 
trans  ♦Al  8  3 
state  7 
trans  ♦Al  7  3 
trans  -02  8  3 
state  8 
trans  ♦Al  8  3 
trans  ♦AO  1  3 
trans  -DO  9  3 
state  9 
trans  ♦Al  9  3 
trans  ♦AO  2  3 
trans  ♦Al  4  3 
naebine  2 
state  1 

trans  ♦BNQ  10  3 
trans  ♦DO  2  3 

state  2 

trana  ♦BID  13  3 
trans  ♦Ol  3  3 
trans  -ACl  4  3 

state  3 

trans  ♦BNQ  14  3 
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CrMM  -ACa  7  3 

■t«ta  4 

tr«M  *03  S  3 
trana  ♦BIQ  31  3 

atata  5 

trana  *mQ  li  3 
trana  -AC3  7  3 
trana  *02  6  3 

atata  4 

trana  -ACO  1  3 
trana  *EtiQ  IS  3 

atata  7 

trana  *BNQ  13  3 
trana  *03  •  3 
atata  4 
trana  -ACO  1  3 
trana  *BMO  IS  3 
trana  *00  9  3 
atata  9 
trana  -ACl  4  3 
trana  *EMg  13  3 
atata  10 
trana  -AO  1  3 
atata  11 
trana  -Al  4  3 
atata  13 
trana  -A3  7  3 
atata  13 
trana  -Al  4  3 
atata  14 
trana  -A3  7  3 
atata  IS 
trana  -AO  1  3 
aaehina  3 
atata  1 
trana  *00  3  1 
trana  *01  3  1 
trana  *03  4  1 
trana  *100  30  4 
trana  *110  31  4 
trana  *130  33  4 
trana  *101  33  4 
trana  *111  34  4 
trana  *131  3S  4 
trana  *103  34  4 
trana  *113  37  4 
trana  *133  38  4 
trana  *ACO  S  3 
trana  *AC1  4  3 
trana  *AC3  7  a 
trana  *RRO  39  4 
trana  *RR1  30  4 
trana  *RR3  31  4 
atata  3 

trana  -ENQ  8  3 

atata  3 

trana  -EHQ  9  2 

atata  4 

trana  -ENQ  10  3 
atata  S 

trana  -RRO  1  4 

atata  4 

trana  -RRl  1  4 

atata  7 

trana  -RR3  1  4 
atata  8 

trana  *A0  11  3 
trana  *A1  13  3 
trana  *A3  13  2 
trana  *ACO  8  3 
trana  *AC1  8  2 
trana  *AC2  8  2 
atata  9 

trana  *A0  14  3 
trana  *A1  IS  2 
trana  *A2  14  2 
trana  *ACO  9  3 
trana  *AC1  9  3 
trana  *AC2  9  2 
atata  10 
trana  *A0  17  2 
trana  *A1  18  2 
trana  *A2  19  2 
trana  *AC0  10  2 
trana  *AC1  10  3 
trana  *AC3  10  3 
atata  11 
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trtM 

•too  1  4 

12 

tr«M 

-101  1  4 

Mf 

12 

truM 

-102  1  4 

scat# 

14 

traos 

-110  1  4 

stats 

IS 

trans 

-Ill  1  4 

stats 

1« 

trans 

-112  1  4 

stats 

17 

trans 

-120  1  4 

stats 

18 

trans 

-121  1  4 

stats 

19 

trans 

-122  1  4 

stats 

20 

trans 

-DO  29  2 

stats 

21 

trans 

-D1  29  2 

stats 

22 

trans 

-02  29  2 

stats 

33 

trans 

-DO  30  2 

stats 

24 

trans 

-D1  30  2 

stats 

2S 

trans 

-D2  30  2 

stats 

26 

trans 

-00  31  2 

stats 

27 

trans 

-D1  31  2 

stats 

28 

trans 

-D2  31  2 

stats 

29 

trans 

-AO  1  1 

stats 

30 

trans 

-A1  1  1 

stats 

31 

trans 

-A2  1  1 

MChlM  4 

stats 

1 

trans 

*D0  2  S 

trans 

*D1  3  S 

trans 

*D3  4  S 

trans 

*100  20  3 

trans 

*110  21  3 

trans 

*120  22  3 

trans 

*101  23  3 

trans 

*111  24  3 

trans 

*121  2S  3 

trans 

*102  26  3 

trans 

*112  27  3 

trans 

*122  28  3 

trans 

*AC0  5  6 

trans 

*AC1  6  6 

trans 

*AC3  7  6 

trans 

*RR0  29  3 

trans 

*RR1  30  3 

trans 

*RR2  31  3 

stats 

2 

trans 

-ENQ  8  6 

stats 

3 

trans 

-ENQ  9  6 

stats 

4 

trans 

-ENQ  10  6 

stats 

S 

trans 

-RRO  1  3 

stats 

6 

trans 

-RRl  1  3 

stats 

7 

trans 

-RR2  1  3 

stats 

8 

trans 

*A0  11  6 

trans 

*A1  12  6 

trans 

*A2  13  6 

trans 

*AC0  8  6 

trans 

*AC1  8  6 

trans 

*AC2  8  6 

stats 

9 

trans 

*A0  14  6 

trans 

*A1  IS  6 

trans 

*A2  16  6 

trans 

*AC0  9  6 

trans 

*AC1  9  6 

trans 

*AC2  9  6 

80 


st«t« 

10 

tr«M 

*u 

17  6 

tntm 

*u. 

18  6 

tr«M 

*K2 

19  6 

trftM 

*jyco 

10  6 

tr«u 

10  6 

trmnm 

tlkCl 

10  6 

mt%tm 

11 

tr«M 

-lOG 

1  1  3 

9ttkf 

12 

traos 

-101 

1  3 

13 

truofl 

-103 

1  1  3 

14 

traoa 

-no 

1  1  3 

•tat« 

IS 

traM 

-111 

1  3 

stata 

16 

traoa 

-113 

!  1  3 

atata 

17 

craoa 

-120 

1  1  3 

fltata 

18 

trana 

-121 

1  3 

ataca 

19 

trana 

-123 

1  1  3 

ataca 

20 

traoa 

-DO 

27  6 

ataca 

21 

traoa 

-D1 

29  6 

atata 

22 

traoa 

-02 

29  6 

atata 

23 

traoa 

-DO 

30  6 

atata 

24 

traoa 

-D1 

30  6 

atata 

25 

traoa 

-02 

30  6 

atata 

26 

traoa 

-DO 

31  6 

atata 

27 

traoa 

-01 

31  6 

atata 

28 

traoa 

-D2 

31  6 

atata 

29 

traoa 

-AO 

1  5 

ataca 

30 

traoa 

-A1 

1  S 

atata 

31 

traoa 

-A3 

1  s 

mcMm  5 

atata 

1 

traoa 

1  4 

traoa 

-00 

3  4 

atata 

2 

traoa 

*A0 

3  4 

traoa 

-01 

3  4 

traoa 

«A1 

4  4 

atata 

3 

traoa 

*A0 

3  4 

traoa 

>A1 

5  4 

traoa 

*K2 

7  4 

atata 

4 

traoa 

♦A1 

4  4 

traoa 

-01 

5  4 

atata 

S 

traoa 

tAl 

S  4 

traoa 

*k2 

7  4 

traoa 

-02 

6  4 

atata 

6 

traoa 

*A1 

6  4 

traoa 

*A0 

1  4 

traoa 

*A3 

8  4 

atata 

7 

traoa 

«A2 

7  4 

traoa 

-D2 

8  4 

atata 

8 

traoa 

«A2 

8  4 

traoa 

*A0 

1  4 

traoa 

-00 

9  4 

atata 

9 

traoa 

«A2 

9  4 

traoa 

2  4 

traoa 

*A1 

4  4 

MChiM  6 

atata 

1 

traoa 

4BNQ  10  4 

traoa 

400 

2  4 
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•t«e«  2 

traM  *aiO  13  4 
traiM  ♦n  3  4 
traas  -Ml  4  4 

ataca  3 

trana  *UIQ  14  4 
trana  -M3  7  4 

ataca  4 

trana  *D1  S  4 
trana  *BI0  11  4 

atata  S 

trana  *010  14  4 
trana  -M3  7  4 
trana  *D3  4  4 

atata  4 

trana  -MO  1  4 
trana  *BMQ  IS  4 

atata  7 

trana  *EIIO  13  4 
trana  *D3  8  4 

atata  8 

trana  -MO  1  4 
trana  *BIIQ  15  4 
trana  *D0  9  4 

atata  9 

trana  -Ml  4  4 

trana  *EtlQ  13  4 

atata  10 

trana  -M  1  4 

atata  11 

trana  -M  4  4 

atata  13 

trana  -A3  7  4 

atata  13 

trana  -A1  4  4 

atata  14 

trana  -A3  7  4 

atata  15 

trana  -AO  1  4 

lnltlal_atata  111111 

flnlah 

The  result  of  Lap-B  ^tytoori  analysis  (I  and  RR  frames) 

SUMHARY  OF  REACHABItilTY  ANALYSIS  (ANALYSIS  COMPLETED) 


Total  nunbar  of  acacas  ganaratad  :  320457 
Nunbar  of  stataa  analyzad  :  300456 
nuabar  of  daadlocks  :  0 
nuabar  of  unspaclflad  racaptions  :  0 
maximum  maaaaga  (juaua  slza  s  5 
channal  ovarflow  :N0NE 

UNEXECUTED  ‘ntANSITIONS 

•****NC«E»***» 


82 


APPENDIX  B  (GO  BACK  N  PROTOCOL) 
Variable  D^nitioiis  (Window  SSae  10) 


with  TBXT_IO;  ua«  TEXT.IO; 
package  daflnlclons  is 

nuai_oC-machlnas  :  constant  :s  2; 
type  acaccransltlon_typa  la 

( an<i_data , rcv_data , rcv_ack0 , rcv_acki ,  rcv_ack2 , rcv_ack3 , rcv_ack4 . rcv_ack5 , rcv_acV  5 , rcv_ack7 
, rcv_ack8, rcv_ack9, sn4_ack, unused) ; 

type  buCfer.type  la  (d0.dl,d2.d3,d4,d5.d6,d7.d8.d9,E) ; 
pac)cage  buf  f_enuiii_lo  la  new  enumeratlon_IO(bu(fer_type) ; 
use  buff.enuBulo; 

type  buffer_array_type  la  array(1..10)  of  )3uffer_type: 
type  se<i_array_type  Is  array(1..10)  of  Integer  range  -1..10; 

type  machlnel_state_type  la 
record 

Sdata:  buf fer_array_type:s 
sag  :  Integer  range  0 . . 10 
1  :  Integer  range  1 . . 10 

end  record; 

type  machlne2_state_type  Is 
record 

Rdata  :  buf fer_type:s  E; 
exp  :  Integer  range  0..10  :a  O; 

j  :  integer  range  1..10  :=  1; 

end  record: 

type  duimy.type  la  range  1..25S; 
type  machlne3_state_type  Is 
record 

dummy:  dummy_type; 
end  record: 


(d0.dl,d2.d3.d4.d5,d6.d7,d8,d9); 
:=  0: 

:=  1; 


type  machlne8_state_type  Is 
record 

dummy:  dummy.type; 
end  record; 

type  global_variable_type  Is 
record 

t)ATA  :  buffer_array_type  :=  (E,E,E,E,E,E,E,E,E,E)  ; 

SEQ  :  seq_array_type  :=  (-1, -1, -1. -1. -1. -1, -1, -1, -1, -1) ; 

ACK  :  Integer  range  -1..10  :=  -1; 
end  record; 
end  definitions; 

Predicate-Action  Table  (Window  Size  10) 


separate (main) 

procedure  Analyze_Predlcates_Machinel ( local  :  machlnel_scate_type; 

global  :  global_variable_type; 
s  :  natural; 

w  :  In  out  transit lon_stack_pac)cage.stac)c)  Is 
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tempi 

Intasar 

IS 

GLOBAL.ACK  < 

0; 

taap2 

Integer 

:  s 

(COABAL.ACX 

♦ 

1) 

mod  11; 

taap3 

Integer 

IS 

(GLOBAL.ACK 

♦ 

2) 

■od  11; 

tamp4 

Integer 

IS 

(GLOBAL.ACK 

♦ 

3) 

■od 

11; 

taapS 

Integer 

IS 

(GLOBAL.ACK 

♦ 

4) 

■od 

11; 

taap6 

Integer 

IS 

(GLOBAL.ACK 

S) 

■Od 

11; 

tanp7 

Integer 

IS 

(GLOBAL.ACK 

♦ 

6) 

nod 

11; 

tanpB 

Integer 

IS 

(GLOBAL.ACK 

♦ 

7) 

nod 

11; 

tanp9 

Integer 

IS 

(GLOBAL.ACK 

♦ 

8) 

nod 

11; 

taaplO 

Integer 

IS 

(GLOBAL.ACK 

♦ 

9) 

nod 

11; 

bagln 


cas*  a  la 
whan  0  s> 

If  (  (GLOBAL. DATA ( local.  1)  s  E  )  and  ( GLOBAL. SEOdoca  1.1)  s 
Puah ( w, and_daca ) ; 
and  If; 
whan  1  » 

If  (  (GLOBAL. OATA(local.l)  s  E  )  and  (GLOBAL. SEQ( local. 1)  = 
Puah(w. and_data) ; 
and  If; 

If  (  (taiapl  s  local. aaq)  and  (GLOBAL. ACK  -l))  chan 

Puah  ( w,  rcv_ac]cO ) ; 
and  If; 
whan  2  s> 

If  (  (GLOBAL. OATA(local.l)  a  E  )  and  (GLOBAL. SEQdoca 1.1)  = 
Puah ( w, 8nd_daca ) ; 
and  If; 

If  (  (Canpl  a  local. aaq)  and  (GLOBAL. ACK  /a  -1))  chan 
Puah(w,  rcv_ac)cO ) ; 
and  if; 

If  (  (CaBp2  a  local. aaq)  and  (GLOBAL. ACK  I-  -D)  than 
Puah  ( w.  rcv.acJcl ) ; 
and  If; 
trtian  3  a> 

If  (  (GLOBAL. DATAdocal.l)  a  E  )  and  (GLOBAL. SEQ (local.  1)  a 
Puah(w, and_daca) ; 
and  If; 

If  (  (Caopl  a  local. aaq)  and  (GLOBAL. ACK  /a  -1))  chan 
Puah(w,  rcv_ac)tO )  ; 
and  If; 

If  (  (cainp2  a  local. aaq)  and  (GLOBAL. ACK  /a  -1))  chan 
Puah(w, rcv_ackl ) ; 
and  If; 

If  (  (Canp3  a  local. aaq)  and  (GLOBAL. ACK  !-  -1))  than 
Puah  ( w,  rcv_ac)c2 )  ; 
and  If; 
trtian  4  a> 


If  (  (GLOBAL. DATAdocal.l)  a  E  )  and  (GLOBAL.  SEQ  (local.  1)  a 
Puah  ( w,  8nd_data ) 
and  If; 

If  (  (tanpl  a  local. aaq)  and  (GLOBAL. ACK  I-  -1))  than 
Pu8h(w,  rcv_ac)cO )  ; 
and  If; 

If  (  (tanp2  a  local. aaq)  and  (GLOBAL. ACK  /a  -1))  than 
Pu8h(w,rcv_ac)cl) ; 
end  If; 

If  (  (tempi  a  local. aaq)  and  (GLOBAL.ACK  I-  -D)  than 
Pu8h(w, rcv_ack2 ) ; 
and  If; 


If  (  (tanp4  a  local. aaq)  and  (GLOBAL.ACK  /a  -1))  than 
Puah  ( w,  rcy_ac)c3 )  ; 


-1)  )  than 


-1)  )  than 


-1)  )  then 


-1)  )  than 


-1)  )  Chen 
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•nd  It; 
wh«n  5  s> 

If  (  (GLOBAL. DATAdocal.l)  ^  B  )  end  (GLOBAL. SEQ( local.!)  x  -1)  )  than 
Push(w,and_daca) > 
and  If; 

If  (  (taapl  X  local. aaq)  and  (GLOBAL. ACK  /x  -1))  than 
Puah(w,  rcv_aclcO) ; 
and  if; 

If  (  (taap2  X  local. aaq)  and  (GLOBAL. ACK  /x  -1))  than 
Pu8h(w,  rcv_acJcl )  ; 
and  If; 

If  (  (tanpl  X  local. saq)  and  (GLOBAL. ACK  /x  -i))  than 
Push(w.  rcv_ac)c2 ) ; 
and  If; 

If  (  (tanp4  X  local. saq)  and  (GLOBAL. ACK  /x  -1))  th«i 
Push  (w,  rcv_ac)c3 ) ; 
and  if; 

If  (  (tanpS  X  local. aaq)  and  (GLOBAL. ACK  /x  -i))  than 
Pu8h(w,  rcv_ac)c4 ) ; 
and  if; 
whan  6  x> 

if  (  (GLOBAL. DATA (loca  1.1)  =  E  )  and  ( GLOBAL. SEQdoca  1.1)  x  -1)  )  than 
Push ( w, snd_data ) ; 
and  If; 

If  (  (tanpl  X  local. saq)  and  (GLOBAL. ACK  /=  -1))  than 
Push  (w,  rcv_ac)cO )  ; 
and  If; 

If  (  (tanp2  X  local. saq)  and  (GLOBAL. ACK  /x  -i) )  than 
Push(w,  rcv_ac)cl)  ; 
and  If; 

If  (  (tanp3  X  local. saq)  and  (GLOBAL. ACK  /x  -1))  than 
Puah(w,  rcv_ac)c2 )  ; 
and  If; 

if  (  (tanp4  X  local. saq)  and  (GLOBAL.ACK  /x  -1))  than 
Pu8h(w,  rcv_ac)t3 ) ; 
and  If; 

If  (  (tanpS  X  local. saq)  and  (GLOBAL.ACK  /=  -1))  than 
Push  ( w,  rcv_ac)c4 )  ; 
and  If; 

If  (  (taiiK>6  X  local. saq)  and  (GLOBAL.ACK  /x  -1))  than 
Push(w,  rcv_ac(c5 )  ; 
and  If; 
whan  7  x> 

If  (  (GLOBAL. DATA (loca 1.1)  x  E  )  and  (GLOBAL. SEQ (local. 1)  x  -1)  )  Chen 
Push ( w, snd_data ) ; 
and  If; 

If  (  (tanpl  X  local. saq)  and  (GLOBAL.ACK  /=  -1))  Chen 
Pu8h(w,  rcv_ac)cO)  ; 
end  If; 

If  (  (Cenp2  X  local. saq)  and  (GLOBAL.ACK  /=  -1))  Chen 
Push  ( w,  rcv_ac(tl )  ; 
end  If; 

If  (  (tenp3  X  local. saq)  and  (GLOBAL.ACK  /=  -1))  Chen 
Push(w,  rcv_ac)c2 )  ; 
end  If; 

If  (  (tainp4  X  local. seq)  and  (GLOBAL.ACK  /=  -D)  Chen 
Push  ( w,  rcv_ac)t3 )  ; 
end  If; 

If  (  (cenpS  X  local. saq)  and  (GLOBAL.ACK  /=  -1))  then 
Pu8h(w,  rcv_ac)t4) ; 
and  If; 
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if  (  (t«ap«  ■  local. ■•q)  and 
Pu8h( w, rcv.ackS ) ; 
and  If; 

If  (  (eaap7  s  local. saq)  and 
Push  ( w,  rcv_aclc6 ) ; 
and  If; 

«ih«i  8  » 

If  <  (aiABAL. DATA ( local. 1)  > 
Puahiv,  snd..data) : 
and  if; 

If  (  (Caapl  s  local. aaq)  and 
Push(w, rcv_ackO ) ; 
and  If; 

if  (  (tanp2  s  local. saq)  and 
Push  ( w,  rcv_ac]cl ) ; 
and  if; 

if  (  (tanp3  >  local. saq)  and 
Push(w.  rcv_ac)c2 )  ; 
end  If; 

If  (  (eanp4  =  local. saq)  and 
Push(w.  rcv_ae)c3) ; 
and  If; 

If  (  (cainpS  =  local. saq)  and 
Push  ( w,  rcv_ac)t4 )  ; 
wid  If; 

if  (  (caap6  s  local. saq)  and 
PushCw,  rcv_ac)cS) ; 
and  If; 

if  (  (taap7  =  local. saq)  and 
Push  ( w.  rcv_ac)c6 ) ; 
and  if; 

if  (  (tanp8  M  local. saq)  and 
Push  ( w,  rcv_ac)c7 )  ; 
and  If; 
whan  9  s> 

If  (  (GLOBAL. OATA( local. 1)  s 
Push(w, snd^daca) ; 
and  If; 

if  (  (Carapl  =  local. saq)  and 
Push  ( w,  rcv_ac)tO ) ; 
and  If; 

if  (  (Cainp2  =  local. saq)  and 
Push(w, rcv_ackl ) ; 
and  if; 

if  (  (tainp3  =  local. saq)  and 
Push(w,  rcv_ac)c2 )  ; 
and  If; 

If  (  (Cairp4  =  local. saq)  and 
Push(w,  rcv_ac)c3 )  ; 
and  if; 

if  (  (campS  =  local. saq)  and 
Push  ( w,  rcv_ac)t4 ) ; 
and  If; 

if  (  (taiqpe  =  local. saq)  and 
PushCw, rcv_ac)t5 )  ; 
and  if; 

if  (  (Caiif>7  =  local. saq)  and 
Push(w,  rcv_ac)t6 )  ; 
and  If; 

if  (  (camp8  s  local. saq)  and 
Push  ( w,  rcv_ac)c7 ) ; 


(GLOBAL.ACX  /«  -D)  than 

(GLOBAL. ACK  /s  -D)  thm 

B  )  and  (GLOBAL. SE(2( local.!)  > 

(GLOBAL. AOC  /»  -D)  than 

(GLOBAL.ACX  /-  -D)  than 

(GLOBAL.ACX  /=  -1))  than 

(GLOBAL.ACX  /=  -1))  than 

(GLOBAL.ACX  /s  -D)  than 

(GLOBAL.ACX  /=  -1))  than 

(GLOBAL.ACX  /=  -1) )  than 

(GLOBAL.ACX  /a  -1))  than 

E  )  and  (GLOBAL. SEQ( local. 1)  = 

(GLOBAL.ACX  /s  -D)  than 

(GLOBAL.ACX  /=  -D)  than 

(GLOBAL.ACX  /=  -1) )  than 

(GLOBAL.ACX  /s  -D)  then 

(GLOBAL.ACX  /=  -D)  then 

(GLOBAL.ACX  /=  -D)  then 

(GLOBAL.ACX  /=  -D)  then 

(GLOBAL.ACX  /s  -1))  than 


-1)  )  thwi 


-1)  )  then 
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•nd  ICt 

It  (  (c«ii«>9  3  local. 8«q)  and  (GLOBAL. ACK  /a  -in  than 
Push(w, rcv_ack8) ; 
and  It; 

It  (  (taaplO  *  local. aaq)  and  (GLOBAL. ACK  />  -1))  thm 
Puah  ( w,  rcv_acl(9 ) ; 
and  if; 
whan  10  «> 

If  (  (tanpl  a  local. saq)  and  (GLOBAL. ACK  /s  -1))  than 
Puah (w. rcv.ackO ) : 
and  If: 

If  (  (tanp2  s  local. aaq)  and  (GLOBAL. ACK  /a  -1))  than 
Puah  ( w,  rcv_ac)cl )  ; 
and  If: 

if  (  (tanp3  s  local. aaq)  and  (GLOBAL. ACK  /s  -1))  than 
Puah (w. rcv_ack2 ) : 
and  If: 

If  (  (tanp4  a  local. aaq)  and  (GLOBAL. ACK  /a  -1))  than 
Puah(w, rcv_ack3 ) ; 
and  If: 

If  (  (tanpS  a  local. aaqi  and  (GLOBAL. ACK  /=  *1))  than 
Puah ( w, rcv_ack4 ) : 
and  if: 

If  (  (taiiK>6  a  local. aaq)  and  (GLOBAL. ACK  /a  -1))  than 
Puah ( w, rcv_ackS ) : 
and  if: 

If  (  (tanp7  a  local. aaq)  and  (GLOBAL. ACK  /-  -D)  than 
Puah  (w,  rcv_ack6 ) 
and  if: 

If  (  (tampS  a  local. aaq)  and  (GLOBAL. ACK  /a  -1))  than 
Puah ( w, rcv^ack? ) : 
and  if; 

If  (  (tanp9  a  local. aaq)  and  (GLOBAL. ACK  /a  -D)  than 
Puah(w, rcv.ackO) : 
and  If: 

if  (  (tamplO  a  local. aaq)  and  (GLOBAL. ACK  /a  •!))  than 
Puah ( w, rcv_ack9 ) : 
and  If: 

whan  othara  a> 
null: 
and  case: 

and  Analyza_Predlcates_Machlnel ; 

separata (main) 

procedure  Analyze_Predlcates_Machlna2 ( local  :  machlna2_state_type; 

global  :  global_varlable_type: 
s  :  natural: 

w  :  In  out  cran8ltlon_8tack_package. stack)  Is 

jaagln 

case  8  is 
when  0  a> 

if  ( (GLOBAL. DATA(local.J)/a  E)  and  (GLOBAL. SEQ Uocal . j )  =  local. exp))  then 
push(w, rcv_data) ; 
and  if: 

whan  1(21314(51617(8(9  => 

if  (GLOBAL. DATA ( local. j)=  E)  then 
Pu8h(‘.’,  snd-ack) ; 
end  if; 

if  ( (GLOBAL. DATA( local.  j)/=  E)  and  (GLOBAL. SEQdocal.  j  )  =  local. e:q>))  then 
Pu8h(w,  rcv_data) 
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•nd  It; 

WlMR  10  M> 

It  (aU)BAL.DATA(local.j)>E)  th«i 
PuahCw, and-ack) ; 
and  It; 

«ihan  othara  >> 
null; 
and  caaa; 

and  Analyza_Pradicata8_Machlna2 ; 


aaparaca(inaln) 

procadura  Analyza_Pradlcataa_Hachlua3 ( local  :  machlna3_acata_typa; 

global  :  global_varlabla_cypa; 
a  :  natural: 

w  :  in  out  tranaltion_atack_packaga.atack)  Is 


bagln 

null; 

end  Analyze_Predlcates_Machlna3 ; 


separata (main) 

procedure  Analyze_Predicates_Hachine8 ( local  :  machine8_state_type; 

global  :  glol9al_varlable_typa; 
a  :  natural; 

w  :  in  out  transitlon_stack_pac)cage. stack)  is 


begin 

null; 

end  Analyze_Predlcace8_Machlne8 ; 


separate  (main) 

procedure  Action  (  ln_sy8tem_state  :  in  out  astate_record_type; 

ln_transition  ;  in  out  sciq_tran8itlon_type; 
out_systen\_8tate  :  in  out  Q8tate_record_type )  is 


l>egln 

case  (In-Cransltlon)  is 
when  snd-data  => 

out_sy8tein_state  .GIjOBAL_VARIABLES  .  DATA  ( in_sy8tein_state .  mach.lnel.state .  i ) :  = 
ln_system_state.inachlnel_state.Sdata(ln_systen\_stace.inachinel_state.  1)  ; 
out_systein_state .  GLOBAL_VARIABLES .  SEQ  ( ln_systeiiv_state .  machlnel.state .  1 ) ;  = 

ln_sys tem_8tate . machlnel.state . seq ; 

out_sy8ten\_state.roachinel_8tate.i;=  (irL.systeflustate.inachlnel_state.l  mod  10)  +1  ; 
out_system_state.machinel_scate.seq  :=( ( (in_syscem_scaCe.machlnel_scace.seq)+l)modll) 
when  rcv_ackO  |rcv_ackl  Ircv_ack2  Ircv_ack3  Ircv_ack4  Ircv_ack5  Ircv_ack6  Ircv_ack7  I 
rcv_ack8  I rcv_ack9  => 

OUt_3y8tem_SCate.GU)BAL_VARIABLES.ACK  ;=  -1; 
when  snd_ack  => 

ouC_system_stace.GLOBAL_VARIABLES.ACK  :=  in_sysCem_state.machlne2_staCe.e;gp; 
out_8y8tem_state.machine2_state.Rdata  :=  e  ; 
whan  rcv_daca  => 

ouC_8yscem_aCaCe . machlne2_stace . Rdata  : s  in_sy8Cem_sCaCe .GLOBAL_VARIABLES . DATA 
{ in_8ystem_state.machlne2_scate. j ) ; 
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OUC_8y8t*m_BCat«.aL0BAI(_VARIABLES.DATA(llL.*yat«m_BCate.lMChin«2.BCae«. j)  :»  E; 
ouc_ByBt«in_Btata .  aLOBAl(_VARlABLBS .  SBQ  ( liv_8y8Caia_BCaca .  machlnaZ.stata .  j )  :  s  - 1 ; 
ouC_8y8Cam_8tata.inachlne2_8tata. j  :s  (ln_ByBtam_BCate.inachlne2_8tata. j  mod  10)  >1; 
out_8y8t«n_8Cata.inachlne2_8Cate.axp:s(  ( (in_8yst«iL.BCaca.iBachlna2_8tata.axp)tl)nod  11) ; 
when  otherB  => 

put (‘Error  In  action  procedure*); 
end  caae; 
end  Action; 

Output  Format 


separate (main) 

procedure  output_Gtuple ( tuple  :  In  out  Oatate_record_type )  Ib 
Isegln 

If  prlnt_header  then 
new_llne(2) ; 

8et_col(7) ; 

put_llne(*  iiiKseq,  l.Sdata)  ,  m2(exp.  J.Rdata)  ,  (DATA,SE(2,ACX)  ■); 
prlnt_header  :=  falae; 
else 

put(*  (*  &  Integer' Image (tuple. machlne_state(l) )  ); 
putC  ,  •); 

put (tuple. fflachlnel_state.8eq. width  =>  1); 
put ( •  ,  • ) ; 

put ( tuple. machlnel_state.l, width  =>  1); 
put ( •  ,  •); 

buff_en\im_lo.put(tuple.machlnel_3tate.Sdata(l) ,  set  =>  upper_case) ; 
put ( •  ,  ■ ) ; 

put(  Integer' Image (tuple.machlne_state(2))  ); 
put ( •  ,  • ) ; 

put ( tuple. machlne2_state. exp, width  =>  1); 
put ( •  ,  ■ ) ; 

put(tuple.machlne2_8tate.j, width  s>  1); 
put ( •  ,  • ) ; 

)3uff_enunv_lo.put(tuple.machlne2_state.Rdata,set  =>  upper_case) ; 
for  1  In  1 . .  10  loop 
put {•,•); 

buff_enum_lo.put(tuple.GLOBAL_VARIABLES.DATA(l) .set  =>  upper_case) ; 
put (•,*); 

put (tuple. GLOBAL_VARI ABLES.SEQ(l) ,  width  s>  1); 
end  loop; 
put ( ■  ,  ■); 

put ( tuple. GLOBAL_VARIABLES.ACK,  Width  =>  1) ; 
put ( •  ] ■ ) ; 
end  If; 

end  output_Gtuple; 

Global  Hash  Function  (Window  Size  10) 

function  GLOBALJiASH  (  curr«nt_gstate  i  Gatate_record_type)  return  Integer  is 
index I  integer  i>0> 
suml , Bum2 i integer) >0 ; 

m  I  Bac)ilne_state_array  :>  current_g8tate.machine_Btate; 

begin 

index  I-  (  (m(8)  *83999)  +  (  m(7)  •  72888)  ♦  (ra(6)  *61997)  ♦  (m(5)  *5995)  + 

-(m(4)  *  46571)  +(m(3)  *  34677)  ♦  (m(2)  *  21323)  ♦  (m(l)  *18203)  )  i 
sunl  )■  t>uffer_type'pos(current_gstate.niachlnel_state.Sdata(current_g8tate.machinel_state.l) ) ; 
sunl  I  •  sunl  +(23323  *current_g8tate .  iiiachinel_state .  seq+311 07  *current_gBtate  .maclilnel_state .  i ) ; 
sunl)>  suml  *(20331*buffer_type'pos(current_g8tate.nac))ine2_state.Rdata)  + 

(19977*current_gstate.niac)ilne2_state.exp+17773*current_gstate.machine2_Btate.  j) )  i 
for  1  in  1 . . 10  loop 

8um2  )■  sum2+buffer_type'po8(current_gstate.global_yarlables.DATA(i) )*1112*1+ 
current_gstate.global_variables.SEQ(i) *3371*2*1) 

end  loop) 

return  ( (lndex*5+8uml*7+ll*Bum2+7231*current_g8tate.global_varlableB.ACK)  mod  1545423); 
end  GLOBALJIASH) 
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Thereailtofi  '  Go  Back  N  Protocol  analyabCWindow  size  10) 

SUMNARY  OP  REACHABILITY  ANALYSIS  (ANALYSIS  COMPLETED) 


Numb«r  of  states  generated  : 30632 
Number  of  states  analyzed  : 30632 
Number  of  deadlocics  :  0 

UNEXECUTED  HUNSITIONS 

•••••NONE***** 

The  result  of  the  Go  back  N  Protocol  analysis(Window  size  12) 

SUMMARY  OP  REACHABILITY  ANALYSIS  (ANALYSIS  COMPLETED) 


Numiser  of  states  generated  :  66655 
Number  of  states  analyzed  : 66655 
Nundser  of  deadlocks  :  0 


UNEXECUTED  TRANSITIONS 

•****NC»}E*****  _ 

The  result  of  the  Go  back  N  Protoad  analysis(Window  size  13) 

SUMMARY  OP  REACHABILITY  ANALYSIS  (ANALYSIS  COMPLETED) 


Number  of  states  generated  : 90210 
Number  of  states  analyzed  : 902 10 
Nundser  of  deadloc)cs  :  0 


UNEXECUTED  TRANSITIONS 

•••••NONE***** 

The  result  of  the  Go  back  N  Protocol  analysis(Window  size  14) 

SUMMARY  OP  REACHABILITY  ANALYSIS  (ANALYSIS  COMPLETED) 


Number  of  states  generated  : 122880 
Number  of  states  analyzed  : 122880 
Number  of  deadloc)cs  :  0 


UNEXECUTED  TRANSITIONS 

*****)]OI]S*****  _ 

The  result  of  the  Go  back  N  Protoad  analysis(Window  size  18) 

SUMMARY  OF  REACHABILITY  ANALYSIS  (ANALYSIS  COMPLETED) 


Number  of  states  generated  :290980 
Nxindser  of  states  analyzed  :290980 
Number  of  deadloc)cs  :  0 


UNEXECUTED  TRANSITIONS 

••••*N(»JE***** 
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